Era medarbetare sparar sannolikt lösenord i webbläsaren redan i dag.

Det går fort. Det känns harmlöst. Och det är ofta precis så ett dåligt arbetssätt får fäste.

En uppmärksammad video från Tom Jøran Sønstebyseter Rønning visar varför frågan är värd att ta på allvar.¹ I videon visas ett kommandofönster där sparade lösenord ser ut att läsas ut ur Microsoft Edge för flera användare. Om sparade lösenord blir möjliga att läsa ut är problemet inte bara tekniskt. Problemet är att samma webbläsare ofta är en genväg in till mejl, kunddata, HR-system, ekonomi och interna verktyg.

Microsoft Edge loads all your saved passwords into memory in cleartext - even when you’re not using them.
— Tom Jøran Sønstebyseter Rønning (@L1v1ng0ffTh3L4N) May 4, 2026

Det första ni ska fråga er är enkelt: skulle något liknande kunna hända hos oss?

Om svaret är “kanske”, då har ni nog redan tillräckligt för att agera.

Executive overview

Det här är inte främst en Edge-fråga. Det här är en fråga om hur ni hanterar autentiseringsuppgifter i verksamheten.

Om personal sparar lösenord i webbläsaren flyttar ni ett känsligt skydd närmare användarens vardag, och ofta längre bort från styrning, uppföljning och tydliga regler. När något går fel blir problemet därför större än själva webbläsaren. Det blir en fråga om åtkomst till mejl, kunddata, HR-system, ekonomi och andra centrala verktyg.

ISO 27001 förbjuder inte ordagrant sparade lösenord i webbläsaren. Men standarden kräver att autentiseringsinformation hanteras styrt, att åtkomst begränsas, att klienter skyddas, att säker autentisering används och att reglerna följs upp. Ett moget arbete enligt ISO 27001 hade därför inte gjort er osårbara, men det hade sannolikt gjort detta arbetssätt mindre vanligt, mindre riskabelt och lättare att upptäcka.

Min rekommendation är enkel: tillåt inte att webbläsaren sparar lösenord för verksamhetskritiska konton. Helst ska ni stänga av funktionen helt för företagskonton och i stället använda ett verktyg som 1Password eller en annan dedikerad lösenordshanterare med tydlig styrning, delning, återkallelse och stark autentisering.

Börja här, så skyddar ni er redan nu

Ni behöver inte vänta på ett stort säkerhetsprojekt för att minska risken.

Gör detta först:

Bestäm vilka konton som aldrig får sparas i webbläsaren. Börja med mejl, admin-konton, HR, ekonomi, CRM och system med personuppgifter.
Kräv starkare autentisering för känsliga konton. Ett enda sparat lösenord ska inte räcka långt.
Gå igenom vilka användare som har för bred åtkomst. Ju mer ett konto kan nå, desto större blir skadan.
Se till att klienter och webbläsare uppdateras snabbt när nya sårbarheter eller risker blir kända.
Bestäm hur ni upptäcker och hanterar avvikelser. Om någon ändå sparar fel typ av konto lokalt måste ni kunna reagera.

Det här löser inte allt. Men det flyttar er bort från ren tur.

Vem drabbas om sparade lösenord läcker?

Många tänker direkt på IT. Det är för snävt.

Det här slår mot hela verksamheten.

Om en användares webbläsare ger åtkomst till mejlen kan angriparen återställa andra lösenord. Om samma användare har sparat inloggning till kundsystem, leverantörsportaler eller interna verktyg får ni ett mycket större problem. Ett enda konto kan bli en väg vidare.

Det är därför denna fråga inte bara handlar om webbläsare. Den handlar om hur ni hanterar autentiseringsuppgifter i verksamheten.

Varför det här händer så ofta

Skälet är sällan dumhet. Skälet är bekvämlighet.

Folk sparar lösenord i webbläsaren för att få jobbet gjort snabbare. De vill slippa avbrott. De vill logga in och gå vidare. Om organisationen inte har tydliga regler, eller om reglerna finns men ingen följer upp dem, då vinner bekvämligheten.

Det är här många företag tappar greppet. Inte för att de saknar teknik. För att de saknar styrning.

ISO 27001 fångar den bristen ganska brutalt. Standarden kräver att de som arbetar för organisationen ska känna till informationssäkerhetspolicyn, hur de bidrar till ett väl fungerande ledningssystem, och följderna av att inte följa kraven.² Det är svårt att hävda att “folk sparar lite som de vill” är förenligt med det.

Så hade ISO 27001 minskat risken från början

ISO 27001 säger inte uttryckligen “spara inte lösenord i webbläsaren”. Standarden använder inte ens ordet lösenord i den här delen av kravbilden. Men den är ändå tydlig på ett mer användbart sätt: autentiseringsinformation ska hanteras styrt, åtkomst ska begränsas, klienter ska skyddas, säker autentisering ska användas, och reglerna ska följas upp.

ISO 27001 hade inte gjort er osårbara. Men ett bra arbete enligt standarden hade gjort tre saker:

minskat sannolikheten att känsliga lösenord sparas fel
begränsat skadan om något ändå läcker
gjort er snabbare på att upptäcka och rätta till problemet

Det är en stor skillnad.

1. ISO 27001 hade tvingat er att bestämma vad som är känsligt

Standarden kräver att ni bedömer informationssäkerhetsrisker och prioriterar dem.³ Den kräver också att information klassas utifrån konfidentialitet, riktighet och tillgänglighet.⁴

I praktiken betyder det att ni inte får behandla alla konton som om de vore likvärdiga.

Ett konto till ett enkelt nyhetsbrevssystem är inte samma sak som ett konto till vd:s mejl eller ert HR-system. När ni väl har klassat informationen blir nästa fråga självklar: vilka inloggningar får över huvud taget sparas i webbläsaren?

Det är en mycket bättre fråga än “får folk göra lite som de vill?“

2. ISO 27001 har faktiskt skrivningar om lösenordshantering

Ja. Inte med ordet “lösenordshanterare” som produktkategori, och inte som ett direkt förbud mot att spara lösenord i webbläsaren. Men mycket nära det ni letar efter.

Den tydligaste skrivningen är Bilaga A 5.17:

Tilldelning och hantering av autentiseringsinformation ska styras med hjälp av en ledningsprocess, som inbegriper att ge råd till personal om hur autentiseringsinformation bör hanteras på lämpligt sätt.

ISO/IEC 27001:2023, Bilaga A 5.17

Autentiseringsinformation är precis det här: lösenord, inloggningsuppgifter och andra sätt att bevisa vem användaren är.⁵

Men det stannar inte där. Bilaga A 5.10 säger också att regler för tillåten användning och rutiner för hantering av information och andra relaterade tillgångar ska identifieras, dokumenteras och tillämpas.⁶ Och Bilaga A 5.16 säger att identiteter ska hanteras under hela deras livscykel.⁷

Standarden kräver också regler för åtkomstkontroll.⁸ Tillsammans betyder det att ni inte kan lämna lösenordshantering till varje användares egna vana.

Det här är kärnan.

Om ni arbetar moget med ISO 27001 finns det regler för sådant här. Inte bara allmänna råd. Faktiska beslut.

Det är därför standarden blir praktiskt användbar här. Den säger inte vilken app ni ska köpa. Den säger att ni måste styra hur autentiseringsuppgifter hanteras.

Till exempel:

vilka typer av konton som inte får sparas lokalt
vilka roller som måste använda starkare autentisering
när en separat lösenordshanterare krävs
vem som får godkänna undantag

Utan sådana beslut blir säkerheten personlig smak. Det håller inte länge.

3. ISO 27001 hade tvingat er att skydda klienterna bättre

Bilaga A är tydlig: “Information som lagras på, behandlas av eller är tillgänglig via användarklienter ska skyddas.”⁹

Det betyder att datorn där någon sparar lösenord inte bara är en arbetsyta. Den är en del av ert skydd.

Standarden kräver också att konfigurationer, inklusive säkerhetskonfigurationer, av hårdvara, programvara, tjänster och nätverk ska fastställas, dokumenteras, implementeras, övervakas och granskas.¹⁰ Det är direkt relevant för webbläsare. Om ni inte styr vilka inställningar som är tillåtna, om lösenord får sparas lokalt, eller vilka tillägg som får köras, då lämnar ni ett stort hål öppet.

Standarden kräver också att ni hämtar in information om tekniska sårbarheter, granskar er exponering och vidtar lämpliga åtgärder.¹¹

Så när en ny risk kring webbläsare eller klientmiljö dyker upp ska ni inte börja från noll. Ni ska redan ha ett arbetssätt för att bedöma:

använder vi detta?
vilka användare berörs?
vilka konton kan påverkas?
vad måste ändras nu?

Det är vad mognad ser ut som.

4. ISO 27001 hade minskat skadan om ett konto ändå läcker

Bra säkerhetsarbete utgår inte från att allt går att stoppa. Det utgår från att skada också måste begränsas.

Därför är åtkomstkontroll så viktig. Om användare har bredare behörighet än de behöver blir varje läckt konto mer värdefullt för en angripare.⁸

Därför är också säker autentisering viktig. ISO 27001 säger att säker autentiseringsteknik och säkra autentiseringsrutiner ska användas utifrån kraven på åtkomstkontroll.¹² Ju känsligare åtkomst, desto mindre rimligt är det att ett sparat lösenord i en webbläsare ska bära hela säkerheten själv.

Det finns också en exakt skrivning i Bilaga A 8.3: åtkomsten till information och andra relaterade tillgångar ska begränsas i enlighet med den fastställda ämnesspecifika policyn för åtkomstkontroll.¹³ Det betyder att även om ett lösenord läcker ska åtkomsten vara strypt av andra beslut ni redan har tagit.

Och därför är dataläckageskydd relevant.¹⁴ Om känslig information behandlas eller lagras på klienter måste ni ha skydd som passar risken. Annars hoppas ni bara att inget händer.

5. ISO 27001 hade gjort er bättre på att upptäcka och lära

Standardens krav på loggning och övervakning spelar också roll här.¹⁵¹⁶

Om ett konto plötsligt används från fel plats, på ett märkligt sätt, eller i mönster som avviker från det normala, då ska det kunna synas. Inte alltid perfekt. Men tillräckligt för att ni ska reagera.

Sedan kommer nästa del, den som många missar. ISO 27001 kräver att ni planerar för incidenthantering, bedömer händelser, hanterar incidenter och lär er av dem.¹⁷¹⁸¹⁹²⁰

Standarden kräver också att efterlevnaden av organisationens informationssäkerhetspolicy, regler och standarder granskas regelbundet.²¹ Om ni har en regel om att känsliga konton inte får sparas i webbläsaren, men aldrig kontrollerar efterlevnaden, då har ni i praktiken ingen regel alls.

Det betyder att ett upptäckt problem inte får stanna vid “det där var inte bra”.

Ni ska reda ut vad som hände. Begränsa skadan. Förstå varför det kunde hända. Och ändra arbetssättet så att samma misstag inte upprepas.

6. ISO 27001 hade gjort det svårare för bekvämlighet att vinna

Det här är kanske den viktigaste punkten.

Standarden kräver utbildning och regelbundna uppdateringar till personalen.²² Den kräver också att organisationen avgör vilken kompetens som behövs, säkerställer att personer har rätt kompetens, och bevarar belägg för den kompetensen.²³ Den kräver också att säkerhetsåtgärder finns när folk arbetar på distans.²⁴

Det är avgörande, för sparade lösenord i webbläsaren är nästan alltid ett beteendeproblem först. Tekniken kommer senare.

Om personalen inte förstår varför vissa genvägar är riskabla kommer de fortsätta ta dem. Om distansarbete sker utan tydliga regler blir privata vanor lätt verksamhetens risk.

Ett moget ISO 27001-arbete gör det svårare att glida in i sådana vanor utan att någon märker det.

Om ni vill ta frågan på allvar, fatta dessa beslut

Ni behöver inte certifiera er i morgon. Men ni behöver fatta riktiga beslut.

Börja med dessa:

bestäm vilka konton som aldrig får sparas i webbläsaren
se över åtkomst för roller med hög påverkan
stärk autentiseringen där skadan vid kontoövertagande är stor
se till att klienter och webbläsare hanteras som säkerhetsfrågor, inte användarpreferenser
sätt en rutin för hur nya sårbarheter och obehagliga demovideor ska bedömas

Det är inte spektakulärt. Det är därför det fungerar.

När blir ISO 27001 relevant på riktigt?

ISO 27001 blir relevant på riktigt när sådana här frågor återkommer gång på gång, men varje gång löses ad hoc.

När ingen vet vilka konton som sparas lokalt.

När regler finns, men ingen följer upp dem.

När klientskydd, åtkomst, utbildning och incidentlärande lever i olika lådor.

Det är då ett ledningssystem börjar bli intressant. Inte som administration. Som sätt att få ordning.

Om ni känner igen er i detta är det rimligt att börja fundera på om tiden är inne att ta ISO 27001-arbetet på allvar, eller att gå hela vägen till certifiering.

Inte för att standarden ordagrant förbjuder sparade lösenord i webbläsaren. För att den tvingar er att sluta lämna sådana beslut åt slumpen.

Inte för att få en logga. För att ni vill slippa bygga säkerheten på bekvämlighet och tur.

Tom Jøran Sønstebyseter Rønning, post on X, 4 May 2026. Verified post text and embed URL: https://x.com/i/status/2051308329880719730. ↩
ISO/IEC 27001:2023, avsnitt 7.3, lokal källa i standardsamlingen. ↩
ISO/IEC 27001:2023, avsnitt 6.1.2, lokal källa i standardsamlingen. ↩
ISO/IEC 27001:2023, Bilaga A 5.12, lokal källa i standardsamlingen. ↩
ISO/IEC 27001:2023, Bilaga A 5.17, lokal källa i standardsamlingen. ↩
ISO/IEC 27001:2023, Bilaga A 5.10, lokal källa i standardsamlingen. ↩
ISO/IEC 27001:2023, Bilaga A 5.16, lokal källa i standardsamlingen. ↩
ISO/IEC 27001:2023, Bilaga A 5.15, lokal källa i standardsamlingen. ↩ ↩²
ISO/IEC 27001:2023, Bilaga A 8.1, lokal källa i standardsamlingen. ↩
ISO/IEC 27001:2023, Bilaga A 8.9, lokal källa i standardsamlingen. ↩
ISO/IEC 27001:2023, Bilaga A 8.8, lokal källa i standardsamlingen. ↩
ISO/IEC 27001:2023, Bilaga A 8.5, lokal källa i standardsamlingen. ↩
ISO/IEC 27001:2023, Bilaga A 8.3, lokal källa i standardsamlingen. ↩
ISO/IEC 27001:2023, Bilaga A 8.12, lokal källa i standardsamlingen. ↩
ISO/IEC 27001:2023, Bilaga A 8.15, lokal källa i standardsamlingen. ↩
ISO/IEC 27001:2023, Bilaga A 8.16, lokal källa i standardsamlingen. ↩
ISO/IEC 27001:2023, Bilaga A 5.24, lokal källa i standardsamlingen. ↩
ISO/IEC 27001:2023, Bilaga A 5.25, lokal källa i standardsamlingen. ↩
ISO/IEC 27001:2023, Bilaga A 5.26, lokal källa i standardsamlingen. ↩
ISO/IEC 27001:2023, Bilaga A 5.27, lokal källa i standardsamlingen. ↩
ISO/IEC 27001:2023, Bilaga A 5.36, lokal källa i standardsamlingen. ↩
ISO/IEC 27001:2023, Bilaga A 6.3, lokal källa i standardsamlingen. ↩
ISO/IEC 27001:2023, avsnitt 7.2, lokal källa i standardsamlingen. ↩
ISO/IEC 27001:2023, Bilaga A 6.7, lokal källa i standardsamlingen. ↩