1. Tokenstöld, den tysta vägen förbi MFA
När en medarbetare loggar in i Microsoft 365 och verifierar sig med MFA skapas en token. Det är ett bevis på att användaren redan har autentiserat sig. Förenklat kan man tänka på en token som en digital nyckel som håller användaren inloggad under en viss tid.
Problemet uppstår om en angripare kommer över den nyckeln utan att känna till lösenordet eller behöva godkänna något på offrets telefon. Då är MFA redan avklarad. Angriparen loggar helt enkelt in som användaren från sin egen dator.
Det här är inte teori. I en kampanj som Microsoft beskrev i sin egen säkerhetsblogg i maj 2026 drabbades 35 000 användare i över 13 000 organisationer under bara några dagar i april. Angriparna kom över giltiga inloggningstoken och tog sig förbi MFA som inte var nätfiskeresistent. Källan är Microsofts egen rapport.
Device code-phishing är en av de metoder som gör exakt det här. Den är dessutom obehagligt enkel att genomföra, eftersom färdigpaketerade nätfiskeverktyg gör attacken tillgänglig även för mindre skickliga angripare.
Den obekväma sanningen är att MFA inte hjälper när angriparen aldrig behöver ta sig förbi den. Låt oss titta på hur det går till.
2. Vad device code flow är (och varför angripare älskar det)
Device code flow är en helt legitim inloggningsmetod från Microsoft. Den är utvecklad för enheter som saknar tangentbord, till exempel en smart-tv, en mötesrumsskärm eller viss IoT-utrustning. I stället för att skriva lösenord på skärmen visar enheten en kort kod och ni skriver in den koden på en dator eller mobil för att logga in.
Tänk på det som när ni loggar in på en app på tv:n. Tv:n visar en kod, ni går till en webbsida på mobilen, skriver in koden och godkänner. Bekvämt och helt ofarligt när det används som det är tänkt.
Problemet är att användaren inte kan avgöra om enheten som väntar på koden faktiskt tillhör den egna organisationen. Angriparen kan starta flödet från sin dator och sedan bara luras att få er att skriva in koden åt dem. Det är därför angripare älskar metoden. Offret gör allt rätt, på riktiga Microsoft och godkänner ändå fel enhet.
3. Så genomförs attacken i fyra steg
Attacken har fyra steg. Det viktiga att lägga märke till är att offret aldrig lämnar den äkta microsoft.com-sidan och aldrig gör något som ser konstigt ut. Allt ser legitimt ut, ända tills angriparen redan har fått åtkomst.
Steg 3 ser helt tryggt ut. Offret loggar in på riktiga Microsoft och klarar sin MFA. Felet sker i steg 4, när godkännandet i själva verket gäller angriparens dator.
Kort sagt: angriparen behöver aldrig ert lösenord och aldrig er telefon. Den enda insatsen är att få er att skriva in en kod och det räcker.
Ett verkligt exempel
En medarbetare på ett företag med 25 anställda får ett mejl som ser ut att komma från en samarbetspartner. I mejlet står att ett dokument väntar och att hon behöver logga in för att läsa det. Det finns en kort kod och en instruktion: gå till microsoft.com, skriv in koden.
Hon gör precis det. Sidan är den äkta Microsoft-sidan. Hon skriver in koden, godkänner med sin MFA på telefonen och allt ser normalt ut. Inget larm, ingen varning, ingen misstänkt länk.
Men koden kom från angriparens dator. Genom att skriva in den godkände hon i praktiken att angriparens dator loggades in som hon. Några minuter senare läser någon annan hennes mejl och letar efter fakturor att ändra. Hon gjorde allt rätt. Det var flödet som var fel.
4. Varför MFA, till och med passkeys, inte räcker här
Det här är den viktigaste insikten i hela artikeln och ofta den mest överraskande. Nätfiskeresistent MFA, som passkeys och FIDO2-nycklar, är utmärkt mot vanligt nätfiske. Men mot device code-phishing hjälper det inte.
Anledningen är enkel. Vid vanligt nätfiske försöker angriparen lura er att autentisera på en falsk sida. Nätfiskeresistent MFA stoppar det, eftersom nyckeln vägrar fungera mot fel adress.
Vid device code-phishing autentiserar offret helt korrekt, på den äkta Microsoft-sidan, med sin riktiga MFA. Det finns ingen falsk sida att stoppa. Felet ligger inte i inloggningen utan i att offret godkänner fel enhet. Därför hjälper det inte att bara införa starkare autentiseringsmetoder.
Det är därför Microsofts rekommenderade åtgärd inte är starkare MFA, utan att blockera själva flödet för de allra flesta användare. Om ni inte använder device code flow, stäng det. Då finns ingen dörr att lura någon igenom.
5. Så stänger ni dörren, steg för steg
Ni stänger device code flow med en Conditional Access-policy. Det är samma regelverk ni redan använder för MFA. Ni behöver Microsoft Entra ID P1, som ingår i Microsoft 365 Business Premium. Nedan följer Microsofts officiella steg.
Steg 1
Granska inloggningsloggarna först
Gå till inloggningsloggarna i Microsoft Entra och filtrera på inloggningsmetod device code. Då ser ni om något legitimt faktiskt använder flödet idag. I de flesta små och medelstora företag används det inte alls.
Steg 2
Skapa en ny Conditional Access-policy
Gå till Conditional Access i Entra admin center och välj Ny policy. Det är samma plats där ni hanterar MFA och andra inloggningsregler.
Steg 3
Rikta policyn mot alla användare
Under Användare väljer ni Alla användare. Under Målresurser väljer ni Alla resurser. Policyn bör omfatta samtliga användare och resurser, eftersom flödet nästan aldrig behövs.
Steg 4
Undanta era nödkonton (break-glass)
Undanta era nödkonton, så kallade break-glass-konton. Det är samma försiktighetsåtgärd som rekommenderas för alla Conditional Access-policys. Om något oväntat inträffar vill ni alltid ha en väg tillbaka in.
Steg 5
Välj villkoret Authentication flows, Device code flow
Under Villkor väljer ni Authentication flows och kryssar i Device code flow. Det är det som gör att policyn träffar just den här inloggningsmetoden och inte vanlig inloggning.
Steg 6
Sätt åtkomstkontrollen till Blockera och kör i rapportläge först
Under Åtkomstkontroller väljer ni Blockera åtkomst. Slå på policyn som Report-only först. Då ser ni vilka inloggningar policyn skulle ha påverkat utan att någon faktiskt stoppas. Granska inloggningsloggarna och när allt ser bra ut ändrar ni läget till På. Det minskar risken för obehagliga överraskningar.
6. Vad blocket gör och inte gör
Var ärlig med vad det här är. Att blockera device code flow stänger en specifik och farlig väg förbi MFA. Det är väl värt att göra och för de flesta företag kostar det ingenting extra eftersom licensen redan ingår.
Men det är viktigt att förstå vad åtgärden gör och inte gör. Den stänger en specifik dörr, inte alla. Nätfiske finns kvar och medarbetare kan fortfarande luras på andra sätt. Blocket ersätter inte MFA, inte utbildning och inte era övriga inloggningsregler. Se det som ett viktigt lager i ett skydd som byggs i flera lager.
En vanlig oro är att blocket ska störa när ni lägger upp nya användare eller inför starkare inloggning. Det gör det inte. Onboarding av nya användare och registrering av passkey sköts med en Temporary Access Pass, en tidsbegränsad engångskod i vanlig webbläsare, inte med device code flow. De som verkligen använder device code flow är i regel CLI-verktyg och tangentbordslösa enheter, till exempel mötesrumsskärmar och det är just därför ni granskar loggarna först.
7. Vanliga frågor
Använder vi ens device code flow?
Nästan aldrig i ett vanligt kontorsföretag. Metoden är gjord för enheter utan tangentbord, som mötesrumsskärmar och viss IoT-utrustning. Granska inloggningsloggarna och filtrera på inloggningsmetod device code för att se om något legitimt använder det innan ni blockerar. I de flesta fall är svaret nej.
Märker användarna av blocket?
I de flesta fall inte. Vanlig inloggning i Outlook, Teams och SharePoint använder inte device code flow och påverkas därför inte. Det är också därför ni börjar i rapportläge. Då ser ni vilka inloggningar policyn skulle ha påverkat innan det börjar tillämpas.
Räcker det här för att stoppa nätfiske?
Nej och det är viktigt att vara ärlig med det. Blocket stänger en specifik och farlig väg, men det stoppar inte nätfiske i sig. Medarbetare kan fortfarande luras på andra sätt. Se det som ett viktigt lager som samverkar med MFA, utbildning och era övriga inloggningsregler.
8. Hur PIANOLA hjälper
PIANOLA analyserar er Microsoft 365-miljö via Microsoft Graph och kontrollerar bland annat om device code flow är blockerat, eller om policyn fortfarande ligger kvar i rapportläge. En policy som ligger kvar i Report-only-läge ger ingen faktisk skyddseffekt.
Vi granskar det dagligen och översätter tekniska säkerhetsinställningar till konkreta rekommendationer på vanlig svenska. I stället för långa tekniska rapporter får ni ett tydligt besked om hur er säkerhetsnivå faktiskt ser ut.
Vet ni om device code flow är blockerat i er Microsoft 365-miljö?
Många företag betalar redan för skyddet genom Microsoft 365 Business Premium utan att använda det. Frågan är därför inte om ni har möjligheten, utan om dörren faktiskt är stängd. En genomgång visar var ni står, device code flow inräknat och vad som saknas.