En lösenordspolicy ska göra det svårare att kompromettera konton utan att försvåra säkert beteende i onödan. De bästa policys är tydliga, praktiska och anpassade för hur människor faktiskt arbetar. De uppmuntrar långa, unika lösenord, stödjer lösenordshanterare, kräver multifaktorautentisering där det är lämpligt och tar bort föråldrade regler som gör att användare skapar förutsägbara lösenord.
\nDen här artikeln förklarar vad en modern lösenordspolicy bör innehålla, vad som bör undvikas, bästa praxis att följa samt innehåller en mall för lösenordspolicy som du kan anpassa för din organisation.
\nEn lösenordspolicy är en uppsättning regler som definierar hur lösenord skapas, lagras, används, delas, ändras och skyddas. Policyn gäller för anställda, konsulter, administratörer, servicekonton och ibland även kunder, beroende på vilka system den omfattar.
\nEn bra lösenordspolicy bör svara på praktiska frågor som:
\nMålet är inte att skapa det mest komplicerade regelverket – utan att minska verklig risk.
\nLängden är ett av de bästa skydden mot gissnings- och brute-force-attacker. Ett enhetligt minimikrav på hela organisationen är ofta lättare att förstå för användare och enklare för IT att upprätthålla än separata regler för vanliga användare, administratörer och specialfall. Ett praktiskt standardkrav är minst 16 tecken för alla användarkonton. Längre är bättre när användare använder lösenordshanterare eller slumpmässigt genererade lösenordsfraser.
\nAnvändare ska kunna skapa lösenord som är betydligt längre än minimikravet. Undvik låga maxgränser som 16 eller 20 tecken. En maximal längd på minst 64 tecken är en rimlig utgångspunkt, och många system klarar ännu längre lösenord.
\nLösenordsfraser bör tillåtas om de är långa och inte baseras på vanliga citat, låttexter, företagsnamn eller förutsägbara fraser. Exempelvis är en fras bestående av flera slumpmässiga ord oftast bättre än ett kort lösenord med påtvingade teckenkombinationer.
\nAlla konton ska ha unika lösenord. Återanvända lösenord är en av de främsta orsakerna till att ett intrång i en tjänst leder till kapning av konton i andra tjänster. En lösenordshanterare gör det praktiskt möjligt för användare att ha unika lösenord, eftersom varje inloggning inte behöver memoreras.
\nPolicyn bör tydligt tillåta och uppmuntra användning av godkända lösenordshanterare. Användare ska kunna klistra in lösenord i inloggningsformulär, använda autofyll och skapa slumpmässiga lösenord. Att blockera inklistring kan kännas säkert, men motverkar ofta starkare användning av lösenordshanterare.
\nLösenord ska avvisas om de förekommer i kända dataläckor, vanliga lösenordslistor eller organisationsspecifika spärrlistor. Detta är långt mer effektivt än att tvinga användare att inkludera versaler, siffror och specialtecken.
\nMultifaktorautentisering ska vara aktiverad där det är tekniskt möjligt, särskilt för administratörer, fjärråtkomst, molntjänster, e-post, lösenordshanterare, ekonomisystem och andra affärskritiska system. MFA ersätter inte starka lösenord men minskar skadan vid stulna legitimationer.
\nAnvänd fiskskyddad MFA som passkeys, hårdvarunycklar eller plattformsautentiserare där det går. App-baserade autentiserare är oftast bättre än SMS. MFA via SMS får inte användas om något annat MFA-alternativ är tekniskt möjligt, eftersom telefonnummer kan kapas, SIM-kort kan bytas, eller missbrukas genom återställningsrutiner.
\nDetta är inte teoretiskt: 2018 uppgav Reddit att angripare avlyssnade SMS-baserad tvåfaktorsautentisering och fick tillgång till interna system: https://www.reddit.com/r/announcements/comments/93qnm5/wehadasecurityincidenthereswhatyouneed_to/. 2021 rapporterade Coinbase att angripare stal kryptovaluta från minst 6 000 kunder efter att ha missbrukat legitimationer och en svaghet i Coinbases återställning via SMS: https://www.reuters.com/technology/coinbase-says-hackers-stole-cryptocurrency-least-6000-customers-2021-10-01/.
\nLösenord ska bytas när det finns bevis eller rimlig misstanke om kompromettering. Exempel är nätfiske, skadlig kod på datorn, läckta uppgifter i ett intrång, misstänkt inloggningsaktivitet eller oavsiktlig exponering.
\nUndvik delade lösenord där individuella konton är möjliga. Om delade autentiseringsuppgifter är oundvikliga, förvara dem i en godkänd lösenordshanterare, begränsa åtkomst till behöriga, och logga delningar där det är möjligt.
\nÅterställning av lösenord är ofta den svagaste länken. Återställningsflöden ska verifiera identitet, låta återställningslänkar löpa ut snabbt, använda engångskoder och meddela när lösenord bytts.
\nObligatoriska lösenordsbyten var 30, 60 eller 90 dag leder ofta till svagare lösenord. Användare ändrar bara små detaljer, som att lägga till en siffra eller byta ut säsong. NIST:s Digital Identity Guidelines har tagit bort periodiska byten och kräver i stället ändring vid misstanke om kompromettering. Se sektion 3.1.1.2: https://pages.nist.gov/800-63-4/sp800-63b.html#passwordver. Kräv byten efter misstänkt kompromettering, förändringar i roll, återställning eller om lösenord inte längre uppfyller policyn.
\nRegler som \"måste innehålla stor bokstav, liten bokstav, siffra och specialtecken\" garanterar inte styrka. Password1! följer många komplexitetsregler men är ändå svagt. Prioritera längd, unikhet, slumpmässighet och screening mot läckta lösenord.
Att blockera inklistring försvårar användning av lösenordshanterare. Det kan leda till kortare och lättare lösenord. Tillåt inklistring och autofyll om det inte finns särskilt dokumenterat säkerhetsskäl att förbjuda det.
\nLösenordsledtrådar avslöjar ofta för mycket. Om användaren kan minnas svaret med hjälp av ledtråden, kan en angripare ofta gissa det också. Använd istället säkra återställningsprocesser.
\nSystem får aldrig lagra lösenord i klartext eller med återställningsbar kryptering. Lösenord ska lagras med en modern, långsam och saltad hash-algoritm som Argon2id, bcrypt, scrypt eller PBKDF2, beroende på systemets och regleringens krav.
\nSnabba allmänna hash-algoritmer som MD5, SHA-1, SHA-256 eller SHA-512 är inte lämpliga för lösenordshashning på egen hand, eftersom de är konstruerade för att vara snabba och därmed underlättar brute-force-attacker efter en databasläcka. För mer bakgrund, se vår artikel om lösenords-hashingens utveckling.
\nLösenord ska inte skickas via e-post, chatt, ärendehanterare, dokument, skärmdumpar eller liknande. Använd lösenordshanterare med säker delning och åtkomstkontroller.
\nLösenord får inte innehålla namn, födelsedagar, företagsnamn, tangentbordsmönster, upprepade tecken eller vanliga växlingar, såsom @ för a och 0 för o. Angripare testar sådana mönster först.
Använd krav som är enkla att förstå:
\nAdministratörskonton, servicekonton och produktionsmiljöer kräver strängare kontroller. Ställ högre lösenordskrav, MFA, begränsad åtkomst, övervakning och omedelbar rotation vid ändrad åtkomst.
\nStarka lösenord kompenserar inte för överdrivna rättigheter. Användare ska endast ha tillgång till de system och hemligheter som behövs i rollen.
\nUpptäck ovanliga inloggningsmönster, orimliga resor, upprepade misslyckade försök, inloggningar från nya länder samt aktivitet utanför normala arbetstider. Lösenordspolicyn bör kompletteras med övervakning och incidenthantering.
\nUtbildningen bör fokusera på lösenordsåteranvändning, nätfiske, falska inloggningssidor, MFA-trötthet, säker delning och hur misstänkt kompromettering rapporteras. Undvik att skuldbelägga användare. Gör det lätt att agera säkert.
\nEn lösenordspolicy ska vara begriplig. Om policyn är för lång, vag eller strikt kommer människor kringgå den. Den bästa policyn är en som faktiskt implementeras.
\nAnvänd följande mall som utgångspunkt. Justera de hakparentesmarkerade delarna efter din organisations system, risknivå och legala krav.
\nLösenordspolicy\n\nVersion: [1.0]\nÄgare: [Säkerhet / IT-avdelning]\nGiltig från: [ÅÅÅÅ-MM-DD]\nGranskningsintervall: [Var 12:e månad]\n\n1. Syfte\n\nDenna policy fastställer krav för skapande, användning, lagring, delning och byte av lösenord inom [Organisationsnamn]. Syftet är att minska risken för obehörig åtkomst, identitetsstöld, kontokapning och dataförlust.\n\n2. Omfattning\n\nDenna policy gäller samtliga anställda, konsulter, tillfällig personal, tjänsteleverantörer och andra som har tillgång till [Organisationsnamn]s system, applikationer, nätverk, molntjänster eller data.\n\nPolicyn gäller vanliga användarkonton, privilegierade konton, servicekonton, delade konton och alla system där lösenord används för autentisering.\n\n3. Krav för lösenordsskapande\n\nAlla lösenord ska uppfylla följande krav:\n\n- Användarkonton ska ha lösenord om minst 16 tecken.\n- Lösenord måste vara unika och får inte återanvändas över arbets- eller privatkonto.\n- Lösenord får inte innehålla namn, användarnamn, företagsnamn, födelsedatum, tangentbordsmönster, upprepade tecken eller annan lättgissad information.\n- Lösenord får inte baseras på vanliga fraser, citat, låttexter eller förutsägbara teckenväxlingar.\n- Lösenord får inte finnas med i kända läckta lösenordslistor eller vanliga lösenordslistor.\n- Lösenord får innehålla mellanslag, symboler, siffror, versaler och gemener.\n- Lösenordsfraser är tillåtna om de är långa, unika och inte baserade på förutsägbara eller publika fraser.\n\n4. Lösenordshanterare\n\n[Organisationsnamn] kräver eller rekommenderar starkt att en godkänd lösenordshanterare används för att skapa, lagra och dela lösenord.\n\nAnvändare får använda lösenordsgenerator, autofyll och kopiera/klistra in-funktion från godkänd lösenordshanterare. Lösenord får inte lagras i webbläsare, kalkylblad, dokument, anteckningsappar, e-post, chatt, skärmdumpar eller ej godkända verktyg.\n\n5. Multifaktorautentisering\n\nMultifaktorautentisering ska vara aktiverad där det är tekniskt möjligt, inklusive men inte begränsat till:\n\n- E-postkonton\n- Fjärråtkomstsystem\n- Konton för lösenordshanterare\n- Molntjänster\n- Administratörskonton\n- Ekonomi-, HR- och andra högrisk-system\n- System klassificerade som [konfidentiella / kritiska]\n\nDär det är möjligt ska användare använda fiskskyddad MFA, såsom passkeys, hårdvarunyckel eller plattformsautentiserare. Autentisering via app är att föredra framför SMS. MFA via SMS är förbjudet om något annat MFA-alternativ är tekniskt möjligt, och får endast användas där inga starkare alternativ finns.\n\n6. Lösenordsändringar\n\nLösenord ska omedelbart bytas när:\n\n- Ett lösenord är känt eller misstänks vara komprometterat\n- En användare matat in ett lösenord på en misstänkt nätfiskesida\n- Ett lösenord delats med obehörig\n- Skadlig kod eller obehörig åtkomst upptäcks på användarens enhet\n- Ett lösenord återfinns i en känd dataläcka\n- En privilegierad användare byter roll eller slutar\n- IT/Säkerhet instruerar användaren att byta lösenord\n\nRutinerade schema-baserade lösenordsbyten krävs inte såvida det inte följer av lag, regelverk, avtal eller teknisk begränsning. Byt inte lösenord genom små, förutsägbara ändringar.\n\n7. Delning av lösenord\n\nLösenord får inte delas via e-post, chatt, ärendesystem, dokument, skärmdumpar, telefonsamtal eller muntlig kommunikation.\n\nDelade autentiseringsuppgifter är endast tillåtna där individuella konton inte är tekniskt möjliga eller efter explicit godkännande av [Säkerhet / IT]. Tillåtna delade lösenord ska förvaras och delas via godkänd lösenordshanterare med åtkomst enbart för behöriga personer.\n\n8. Privilegierade konton\n\nPrivilegierade konton måste ha unika lösenord som aldrig används för vanliga användarkonton. Privilegierade konton ska använda MFA om det är tekniskt möjligt och granskas regelbundet.\n\nPrivilegierade lösenord ska roteras när administratör slutar, byter roll, inte längre behöver åtkomst eller vid misstänkt kompromettering.\n\n9. Servicekonton och applikationshemligheter\n\nLösenord, API-nycklar, tokens och applikationshemligheter för servicekonton ska lagras i ett godkänt hemlighetshanteringssystem eller lösenordshanterare.\n\nServicekontons autentiseringsuppgifter får inte hårdkodas i källkod, konfigurationsfiler, bilder, dokumentation eller skript om de inte skyddas via godkänd process.\n\n10. Lösenordsåterställning och kontorecovery\n\nProcesser för lösenordsåterställning ska verifiera användarens identitet före åtkomst ges. Återställningslänkar och tillfälliga lösenord ska vara engångsanvändning, löpa ut snabbt och skickas via godkända kanaler.\n\nAnvändare ska meddelas när lösenord byts eller återställs. Tillfälliga lösenord ska bytas vid första inloggning.\n\n11. Tekniska krav\n\nSystem som lagrar eller behandlar lösenord ska:\n\n- Aldrig lagra lösenord i klartext.\n- Hasha lösenord med modern, saltad algoritm: PBKDF2, scrypt, bcrypt eller Argon2.\n- Inte använda MD5, SHA-1, SHA-256, SHA-512 eller andra snabba hash-algoritmer för lösenord.\n- Skydda autentiseringsgränssnitt med rate limiting eller likvärdiga skydd.\n- Avvisa svaga, vanligt förekommande och kända läckta lösenord.\n- Tillåta inklistring av lösenord från lösenordshanterare.\n- Stödja rimlig lösenordslängd, minst 64 tecken där tekniskt möjligt.\n- Logga säkerhetsrelevanta autentiseringshändelser.\n\n12. Rapportering av misstänkt kompromettering\n\nAnvändare ska omedelbart rapportera misstänkt kompromettering av lösenord, nätfiske, ovanliga inloggningsdialoger, MFA-prompter som användaren inte själv initierat eller oavsiktligt utlämnade lösenord till [Säkerhet / IT-kontakt].\n\n13. Undantag\n\nUndantag från denna policy ska dokumenteras, riskvärderas, tidsbegränsas och godkännas av [Säkerhets-/IT-ledning]. Kompenserande åtgärder ska tillämpas där det är möjligt.\n\n14. Efterlevnad\n\nUnderlåtenhet att följa denna policy kan leda till åtkomststopp, obligatorisk säkerhetsutbildning, disciplinära åtgärder eller andra insatser enligt [Organisationsnamn]s rutiner och tillämplig lag.\n\n15. Granskning\n\nPolicyn ska ses över minst årligen eller efter betydande förändringar i system, hot, regelkrav eller verksamheten.\nEn stark lösenordspolicy handlar inte om att göra livet surt med lösenord. Det handlar om att ta bort svaga rutiner, stödja lösenordshanterare, införa MFA och reagera snabbt vid exponeringar. Håll policyn praktisk, möjlig att upprätthålla och fokuserad på verkliga hot som nätfiske, credential stuffing, återanvända eller komprometterade konton.
","frontmatter":{"date":"May 07, 2026","slug":"password-policy-dos-donts-best-practices","title":"Lösenordspolicy: Saker att göra, att undvika, bästa praxis och en mall att kopiera","description":"Lär dig vad en modern lösenordspolicy bör kräva, vilka föråldrade regler som bör undvikas, och kopiera en praktisk mall för din organisation.","author":"Sascha Pfeiffer","featuredImage":null}}},"pageContext":{"slug":"password-policy-dos-donts-best-practices","lang":"sv","langPathPrefix":"/sv"}},"staticQueryHashes":["2149092236","3128451518","3192060438"]}