En passordpolicy skal gjøre kontoer vanskeligere å kompromittere uten å gjøre sikker oppførsel unødvendig vanskelig. De beste policyene er tydelige, praktiske og tilpasset hvordan folk egentlig jobber. De oppmuntrer til lange, unike passord, støtter passordadministratorer, krever flerfaktorautentisering der det er hensiktsmessig, og fjerner utdaterte regler som får brukere til å velge forutsigbare løsninger.
\nDenne artikkelen forklarer hva du bør og ikke bør gjøre i en moderne passordpolicy, hva som bør unngås, beste praksis å følge, og gir deg en ferdig mal du kan tilpasse til din virksomhet.
\nEn passordpolicy er et sett med regler som definerer hvordan passord skal lages, lagres, brukes, deles, endres og beskyttes. Den gjelder for ansatte, konsulenter, administratorer, tjenestekontoer og noen ganger kunder – avhengig av hvilke systemer som inngår.
\nEn god passordpolicy bør svare på praktiske spørsmål:
\nMålet er ikke å lage det mest kompliserte regelsettet. Målet er å redusere reell risiko.
\nLengde er et av de sterkeste forsvarene mot gjetting og brute-force angrep. Ett felles minimumskrav for hele organisasjonen er ofte enklere både å forstå for brukerne og å håndheve for IT enn å ha ulike regler for brukere, administratorer og spesielle tilfeller. Et praktisk utgangspunkt er å kreve minst 16 tegn for alle menneskelige brukerkontoer. Jo lengre, jo bedre—spesielt hvis brukerne benytter passordadministrator eller tilfeldige passfraser.
\nBrukere bør kunne lage passord som er langt lengre enn minimumet. Unngå lave makslengder som 16 eller 20 tegn. Et maksimalt antall på minst 64 tegn er et fornuftig utgangspunkt, og mange systemer kan støtte enda mer.
\nPassfraser bør være tillatt hvis de er lange og ikke bygger på kjente ordtak, sangtekster, firmanavn eller forutsigbare fraser. For eksempel vil en passfrase bestående av flere tilfeldige ord som regel gi bedre sikkerhet enn et kort passord med påtvungede spesialtegn.
\nAlle kontoer skal ha unike passord. Gjenbruk av passord er en hovedårsak til at angrep på én tjeneste fører til kontoovertakelse andre steder. En passordadministrator gjør det praktisk å bruke unike passord—brukerne slipper å huske alle.
\nDin policy bør eksplisitt tillate og oppmuntre til bruk av godkjente passordadministratorer. Brukere skal kunne lime inn passord i innloggingsfelt, bruke autofyll og generere tilfeldige passord. Å blokkere innliming kan oppleves som beskyttende, men fører ofte til at sterke passord fra administrator ikke benyttes.
\nPassord skal avvises hvis de finnes på kjente oversikter over lekkede eller vanlige passord, eller egne forbuds-/“deny”-lister for virksomheten. Dette er mer effektivt enn å tvinge brukerne til å inkludere én stor bokstav, ett tall og ett symbol.
\nFlerfaktorautentisering (MFA) bør være slått på der det teknisk lar seg gjøre, spesielt for administratorer, fjerninnlogging, skytjenester, e-post, passordadministratorer, økonomisystemer og andre verdifulle IT-systemer. MFA erstatter ikke sterke passord, men reduserer risikoen hvis passordet blir stjålet.
\nForetrekk phishing-resistent MFA slik som passnøkler, maskinvarebaserte sikkerhetsnøkler, eller plattformsautentikatorer. App-baserte autentikatorer er i de fleste tilfeller bedre enn SMS. SMS-baserte løsninger skal ikke brukes dersom noen annen MFA-metode er teknisk mulig, da telefonnumre kan avlyttes, SIM-bytte kan forekomme, nummeret kan overtas eller misbrukes via prosesser for kontogjenoppretting.
\nDette er ikke teori: I 2018 varslet Reddit at angripere avlyttet SMS-basert tofaktorautentisering og fikk tilgang til interne systemer: https://www.reddit.com/r/announcements/comments/93qnm5/wehadasecurityincidenthereswhatyouneed_to/. I 2021 rapporterte Coinbase at angripere stjal kryptovaluta fra minst 6 000 kunder etter å ha misbrukt påloggingsinformasjon og en svakhet i Coinbases SMS-gjenopprettingsprosess: https://www.reuters.com/technology/coinbase-says-hackers-stole-cryptocurrency-least-6000-customers-2021-10-01/.
\nPassord skal byttes når det foreligger bevis eller rimelig mistanke om kompromittering. Eksempler er phishing, skadevare på brukerens enhet, eksponering i datalekkasje, mistenkelig innlogging eller utilsiktet avsløring.
\nDelte passord bør unngås når individuelle kontoer er mulig. Hvis delte innlogginger er uunngåelig, må de lagres i en godkjent passordadministrator, tilgangen skal begrenses til autoriserte brukere, og delingen skal logges om mulig.
\nRutiner for tilbakestilling av passord er ofte det svakeste leddet i kontosikkerheten. Identitet skal verifiseres ved tilbakestilling, lenker må utløpe raskt, kun brukes én gang, og brukeren skal varsles når passordet er endret.
\nObligatorisk bytte av passord hver 30., 60. eller 90. dag fører ofte til svakere passord. Brukere tyr gjerne til små, forutsigbare variasjoner, som å legge til et tall eller bytte årstid. NISTs retningslinjer for digital identitet (Digital Identity Guidelines) har droppet krav om jevnlige bytter og stiller nå kun krav ved mistanke om kompromittering. Se seksjon 3.1.1.2: https://pages.nist.gov/800-63-4/sp800-63b.html#passwordver. Krev bytte etter mistanke om kompromitt, rolleendringer, kontogjenoppretting, eller når passordet ikke lenger oppfyller policyen.
\nRegler som “må inneholde stor bokstav, liten bokstav, tall og symbol” gir ikke garantert sikkerhet. Password1! tilfredsstiller mange slike regler, men er fortsatt svakt. Prioriter lengde, unikhet, tilfeldighet og screening mot kompromitterte passord.
Å blokkere innliming gjør det vanskeligere å bruke passordadministrator. Dette kan føre til at brukeren velger enklere passord som er lettere å skrive inn. Tillat kopier/lim inn og autofyll, med mindre det finnes en spesifikk, dokumentert sikkerhetsrisiko.
\nHint til passord avslører ofte for mye. Hvis en bruker kan huske svaret ut fra hintet, kan en angriper nok også gjette det. Bruk heller sikre tilbakestillingsrutiner.
\nSystemer skal aldri lagre passord i klartekst eller reversibel kryptering. Passord skal hashes med en moderne, treg og saltet algoritme som Argon2id, bcrypt, scrypt eller PBKDF2—avhengig av krav og systemstøtte.
\nRaske hashalgoritmer som MD5, SHA-1, SHA-256 eller SHA-512 egner seg ikke til passord i seg selv, da de er laget for å være raske, noe som gir lettere brute-force etter datalekkasje. Les mer i vår artikkel om utviklingen av passordhashing.
\nPassord skal ikke sendes via e-post, chat, supportsaker, dokumenter eller skjermbilder. Bruk en passordadministrator med sikker deling og tilgangskontroller.
\nPassord må ikke inneholde navn, bursdager, firmanavn, tastaturmønstre, repeterte tegn eller vanlige erstatninger som @ for a og 0 for o. Angripere tester slike mønstre tidlig.
Bruk krav som er lette å forstå:
\nAdministratorkontoer, tjenestekontoer og produksjonstilgang skal ha ekstra strenge krav: sterkere passord, MFA, begrenset tilgang, overvåking og umiddelbar utskifting ved tilgangsendringer.
\nSterke passord kan ikke kompensere for overdrevne tilganger. Brukere skal bare få tilgang til systemene og hemmelighetene de trenger for sin rolle.
\nOppdag uvanlige innloggingsmønstre, umulig reise, gjentatte feilforsøk, innlogging fra nye land og tilgang utenom normalt arbeidstid. Passordpolicyen bør støttes av overvåkning og hendelseshåndtering.
\nOpplæringen bør vektlegge passordgjenbruk, phishing, falske innloggingssider, MFA-tretthet, sikker deling, og hvordan rapportere mistanke om kompromittering. Ikke gi brukerne skyldfølelse. Gjør det lett å velge sikkerhet.
\nPassordpolicyen skal kunne forstås. Er policyen for lang, uklar eller for streng, vil folk omgå den. Den beste policyen er den som faktisk kan håndheves og følges.
\nBruk denne malen som utgangspunkt. Tilpass tekst i klammer til din virksomhet, systemer, risikonivå og rettslige krav.
\nPassordpolicy\n\nVersjon: [1.0]\nEier: [Sikkerhets-/IT-avdeling]\nIkrafttredelsesdato: [ÅÅÅÅ-MM-DD]\nRevisjonssyklus: [Hvert 12. måned]\n\n1. Formål\n\nDenne policyen definerer kravene til opprettelse, bruk, lagring, deling og endring av passord i [Organisasjonsnavn]. Formålet er å redusere risikoen for uautorisert tilgang, stjålne legitimasjoner, kontoovertakelse og tap av data.\n\n2. Omfang\n\nDenne policyen gjelder for alle ansatte, konsulenter, midlertidige ansatte, tjenesteleverandører og alle andre som får tilgang til [Organisasjonsnavn] sine systemer, applikasjoner, nettverk, skytjenester eller data.\n\nDenne policyen gjelder vanlige brukerkontoer, privilegerte kontoer, tjenestekontoer, delte kontoer og alle systemer hvor passord brukes til autentisering.\n\n3. Krav til opprettelse av passord\n\nAlle passord må oppfylle følgende krav:\n\n- Kontoer for menneskelige brukere må ha passord på minst 16 tegn.\n- Passord må være unike og må ikke gjenbrukes mellom jobb- og personlige kontoer.\n- Passord må ikke inneholde navn, brukernavn, firmanavn, bursdager, tastaturmønstre, repeterte tegn eller annen lett gjetbar informasjon.\n- Passord må ikke være basert på vanlige fraser, sitater, sangtekster eller forutsigbare erstatninger.\n- Passord må ikke finnes i kjente lister over lekkede eller vanlige passord.\n- Passord kan inneholde mellomrom, symboler, tall, store og små bokstaver.\n- Passfraser er tillatt hvis de er lange, unike og ikke bygger på forutsigbare eller offentlige fraser.\n\n4. Passordadministratorer\n\n[Organisasjonsnavn] krever eller sterkt anbefaler bruk av godkjent passordadministrator for opprettelse, lagring og deling av passord.\n\nBrukere kan benytte passordgenerator, autofyll og kopi–lim inn fra godkjent passordadministrator. Passord må ikke lagres i nettlesere, regneark, dokumenter, notatapper, e-post, chatmeldinger, skjermbilder eller ikke-godkjente verktøy.\n\n5. Flerfaktorautentisering\n\nFlerfaktorautentisering (MFA) skal være aktivert hvor det er teknisk mulig, inkludert men ikke begrenset til:\n\n- E-postkontoer\n- Fjerninnloggingssystem\n- Passordadministratorkontoer\n- Skytjenester\n- Administratorkontoer\n- Finans-, HR- og andre høyrisikosystemer\n- Alle systemer klassifisert som [konfidensiell / kritisk]\n\nDer det er mulig skal brukere benytte phishing-resistente MFA-metoder som passnøkler, maskinvarebaserte sikkerhetsnøkler eller plattformsautentikatorer. Apper for tofaktorautentisering er å foretrekke fremfor SMS. SMS-basert MFA er forbudt dersom noen annen MFA-metode teknisk er mulig, og kan bare brukes hvis ingen sterkere MFA er tilgjengelig.\n\n6. Endring av passord\n\nPassord må byttes umiddelbart når:\n\n- Et passord er kjent eller mistenkt kompromittert.\n- En bruker har skrevet passordet inn på en mistenkt phishing-side.\n- Passord er delt med uvedkommende.\n- Det er påvist skadevare eller uautorisert tilgang på en brukers enhet.\n- Passordet finnes i kjente datalekkede passordlister.\n- En privilegert brukers rolle eller ansettelsesforhold endres.\n- IT eller Sikkerhet gir beskjed om bytte.\n\nRutinemessig utløp av passord er ikke påkrevd med mindre lov/forskrift/kontrakt/systemkrav tilsier det. Passord skal ikke byttes ved små, forutsigbare endringer av det gamle.\n\n7. Deling av passord\n\nPassord skal ikke deles via e-post, chat, supportsaker, dokumenter, skjermbilder, telefonsamtaler eller muntlig kommunikasjon.\n\nDelte innlogginger er kun tillatt når individuelle kontoer ikke er teknisk mulig eller når dette godkjennes eksplisitt av [Sikkerhet / IT]. Godkjente delte innlogginger skal lagres/ deles via godkjent passordadministrator, med tilgang begrenset til autoriserte brukere.\n\n8. Privilegerte kontoer\n\nPrivilegerte kontoer må bruke unike passord som ikke benyttes på vanlige brukerkontoer. MFA skal brukes for disse kontoene der teknisk mulig og gjennomgås regelmessig.\n\nPrivilegerte passord må skiftes når en administrator slutter, bytter rolle, ikke lenger trenger tilgang eller ved mistanke om kompromitt.\n\n9. Tjenestekontoer og applikasjonshemmeligheter\n\nPassord til tjenestekontoer, API-nøkler, tokens og applikasjonshemmeligheter skal lagres i godkjent løsning for hemmelighets-håndtering eller godkjent passordadministrator.\n\nDisse må ikke lagres i kildekode, konfigurasjonsfiler, bilder, dokumentasjon eller skript uten beskyttelse gjennom godkjent løsning for hemmelighetshåndtering.\n\n10. Tilbakestilling og gjenoppretting av konto\n\nRutiner for tilbakestilling av passord må verifisere brukerens identitet før tilgang gjenopprettes. Tilbakestillingslenker og midlertidige passord må være engangs, utløpe raskt, og sendes via godkjent kanal.\n\nBruker skal varsles når passordet byttes/gjenopprettes. Midlertidig passord må endres ved første innlogging.\n\n11. Tekniske kontroller\n\nSystemer som lagrer eller behandler passord må:\n\n- Aldri lagre passord i klartekst.\n- Hashe passord med moderne, saltet algoritme: PBKDF2, scrypt, bcrypt eller Argon2.\n- Ikke bruke MD5, SHA-1, SHA-256, SHA-512 eller andre raske hashalgoritmer alene til passord.\n- Beskytte innloggingsendepunkter med ratevern eller tilsvarende tiltak.\n- Avvise vanlige, svake og kjente kompromitterte passord.\n- Tillate innliming av passord fra passordadministrator.\n- Tillate rimelig lengde, minimum 64 tegn der teknisk mulig.\n- Logge sikkerhetsrelevante autentiseringshendelser.\n\n12. Rapportering av mistanke om kompromitt\n\nBrukere må umiddelbart rapportere mistanke om kompromittert passord, phishing, uvanlige innloggingsforespørsler, MFA-forespørsler de ikke selv initierte eller utilsiktet eksponering av passord til [Sikkerhet / IT-kontakt].\n\n13. Unntak\n\nUnntak fra denne policyen må dokumenteres, risikovurderes, tidsbegrenses og godkjennes av [Leder for Sikkerhet / IT]. Kompenserende tiltak må benyttes om mulig.\n\n14. Håndheving\n\nBrudd på policyen kan føre til fjerning av tilgang, krav om obligatorisk sikkerhetsopplæring, disiplinære tiltak eller andre tiltak i tråd med [Organisasjonsnavn]s retningslinjer og gjeldende lov.\n\n15. Revisjon\n\nPolicyen skal revideres minst årlig eller etter vesentlige endringer i systemer, trusselbilde, lovkrav eller virksomhet.\nEn god passordpolicy handler ikke om å gjøre passord til et ork – den handler om å fjerne svake rutiner, støtte passordadministrator, bruke MFA og rask respons når legitimasjoner lekker. Hold policyen praktisk, håndhevbar og rettet inn mot reelle trusler som phishing, stjålne brukernavn/passord, gjenbruk av passord og kompromitterte kontoer.
","frontmatter":{"date":"May 07, 2026","slug":"password-policy-dos-donts-best-practices","title":"Passordpolicy: Gjør og ikke gjør, beste praksis og en ferdig mal for bedrifter","description":"Lær hva en moderne passordpolicy bør kreve, hvilke utdaterte regler du bør unngå, og få en praktisk mal du kan bruke i organisasjonen.","author":"Sascha Pfeiffer","featuredImage":null}}},"pageContext":{"slug":"password-policy-dos-donts-best-practices","lang":"no","langPathPrefix":"/no"}},"staticQueryHashes":["2149092236","3128451518","3192060438"]}