En password-politik skal gøre konti sværere at kompromittere uden at gøre sikker adfærd unødigt vanskelig. De bedste politikker er tydelige, praktiske og tilpasset, hvordan folk faktisk arbejder. De opmuntrer til lange, unikke adgangskoder, understøtter password managers, kræver multi-faktor autentificering, hvor det er relevant, og fjerner forældede regler, der får brugere til at udvise forudsigelig adfærd.
\nDenne artikel forklarer do's and don'ts for en moderne password-politik, hvad der skal undgås, bedste praksis man bør følge, og giver en copy-paste-skabelon, du kan tilpasse til din organisation.
\nEn password-politik er et sæt regler, der definerer, hvordan adgangskoder oprettes, opbevares, bruges, deles, ændres og beskyttes. Den gælder for ansatte, konsulenter, administratorer, servicekonti og til tider også kunder, afhængig af systemerne omfattet af politikken.
\nEn god password-politik bør besvare praktiske spørgsmål:
\nMålet er ikke at skabe det mest komplicerede regelsæt. Målet er at reducere reel risiko.
\nLængde er en af de stærkeste forsvar mod gætteri og brute-force angreb. Én samlet minimumslængde for hele organisationen er ofte nemmere at forstå for medarbejderne og for IT at håndhæve end særskilte regler for forskellige brugergrupper. Et praktisk udgangspunkt er at kræve mindst 16 tegn for alle menneskelige bruger-konti. Længere er bedre, når brugere anvender password managers eller tilfældige adgangssætninger.
\nBrugere bør kunne oprette adgangskoder, der er meget længere end minimum. Undgå lave maksimumsgrænser som 16 eller 20 tegn. En maksimumslængde på mindst 64 tegn er et fornuftigt udgangspunkt, og mange systemer kan understøtte endnu mere.
\nAdgangssætninger bør være tilladt, hvis de er lange og ikke er baseret på gængse citater, sangtekster, firmanavne eller forudsigelige sætninger. For eksempel er en adgangssætning sammensat af flere tilfældige ord oftest bedre end en kort kode med tvungne udskiftninger.
\nHver konto skal have en unik adgangskode. Genbrug af adgangskoder er en af hovedårsagerne til, at et brud ét sted kan føre til overtagelse af konti et andet sted. En password manager gør unikke adgangskoder praktiske, fordi brugeren ikke behøver huske alle legitimationsoplysninger.
\nDin politik bør eksplicit tillade og opfordre til brug af godkendte password managers. Brugere bør have lov til at indsætte adgangskoder i loginformularer, bruge autofyld og generere tilfældige adgangskoder. At blokere indsætning kan føles beskyttende, men det modvirker ofte god brug af password manager.
\nAdgangskoder skal afvises, hvis de optræder i kendte brud-lister, ofte brugte adgangskoder eller organisationens egen blokeringsliste. Dette er mere nyttigt end at tvinge brugerne til at inkludere ét stort bogstav, ét tal og et symbol.
\nMulti-faktor autentificering skal aktiveres, hvor det teknisk er muligt, især for administratorer, fjernadgang, cloud-tjenester, e-mail, password managers, økonomi-systemer og andre systemer med høje værdier. MFA erstatter ikke stærke adgangskoder, men reducerer konsekvensen af stjålne adgangskoder.
\nForetræk phishing-resistent MFA som passkeys, hardware security keys eller platform authenticatorer. App-baserede authenticatorer er ofte bedre end SMS. SMS-baseret MFA må ikke bruges, hvis andre MFA-metoder teknisk er mulige, fordi telefonnumre kan aflyttes, SIM-swappes, videresendes eller misbruges via kontogendannelsesprocesser.
\nDette er ikke teoretisk. I 2018 oplyste Reddit, at hackere havde aflyttet SMS-baseret to-faktor-autentificering og opnået adgang til interne systemer: https://www.reddit.com/r/announcements/comments/93qnm5/wehadasecurityincidenthereswhatyouneed_to/. I 2021 rapporterede Coinbase, at hackere stjal kryptovaluta fra mindst 6.000 kunder, efter de misbrugte adgangsoplysninger og en svaghed i Coinbases SMS konto-gendannelsesproces: https://www.reuters.com/technology/coinbase-says-hackers-stole-cryptocurrency-least-6000-customers-2021-10-01/.
\nAdgangskoder skal skiftes, når der er beviser eller rimelig mistanke om kompromittering. Eksempler inkluderer phishing, malware på brugerens enhed, eksponering i et data-brud, mistænkelig loginaktivitet eller utilsigtet offentliggørelse.
\nDelte adgangskoder bør undgås, hvor individuelle konti er mulige. Hvis delte legitimationsoplysninger er uundgåelige, skal de gemmes i en godkendt password manager, adgangen skal begrænses til autoriserede brugere, og delinger bør logges, hvis muligt.
\nNulstilling af adgangskoder er ofte det svageste punkt i kontosikkerheden. Nulstillingsworkflows skal verificere identitet, udløbe nulstillingslinks hurtigt, bruge engangstokens og underrette brugeren, når adgangskoden ændres.
\nPåbudte adgangskodeskift hver 30., 60. eller 90. dag fører ofte til svagere adgangskoder. Brugere foretager typisk små, forudsigelige ændringer som at tilføje et tal eller skifte årstid. NIST's Digital Identity Guidelines har droppet rutinemæssige periodiske adgangskodeskift og kræver i stedet skift ved bevis for kompromittering. Se afsnit 3.1.1.2: https://pages.nist.gov/800-63-4/sp800-63b.html#passwordver. Kræv adgangskodeskift efter mistanke om kompromittering, ved rolleændringer, kontogendannelse eller når en kode ikke længere lever op til politikken.
\nRegler som ”skal indeholde store og små bogstaver, tal og symboler” garanterer ikke styrke. Password1! opfylder mange kompleksitetskrav, men er stadig svag. Prioritér længde, unikhed, tilfældighed og screening mod kompromitterede adgangskoder.
Blokering af indsætning gør password managers sværere at bruge. Det kan føre til, at brugeren vælger kortere adgangskoder, der er lettere at taste. Tillad indsætning og autofyld, medmindre der er en specifik og dokumenteret sikkerhedsgrund til ikke at gøre det.
\nAdgangskode-hints afslører ofte for meget. Kan brugeren huske svaret ud fra et hint, kan en angriber måske også gætte det. Brug sikre nulstillingsprocesser i stedet.
\nSystemer må aldrig gemme adgangskoder i klartekst eller reversibel kryptering. Adgangskoder bør hashes med en moderne, langsom, saltet password hashing-algoritme som Argon2id, bcrypt, scrypt eller PBKDF2 afhængig af systemmuligheder og lovkrav.
\nHurtige, generelle hash-algoritmer som MD5, SHA-1, SHA-256 eller SHA-512 er ikke passende til password hashing alene. De er designet til at være hurtige, hvilket gør offline brute-force angreb lettere efter et databasebrud. Læs mere i vores artikel om udviklingen af password hashing.
\nAdgangskoder skal ikke sendes via e-mail, chat, tickets, dokumenter eller skærmbilleder. Brug i stedet password manager med sikker deling og adgangsstyring.
\nAdgangskoder må ikke indeholde navne, fødselsdatoer, virksomhedsnavne, tastaturmønstre, gentagne tegn eller gængse udskiftninger som @ for a og 0 for o. Angribere tester disse mønstre først.
Brug krav, der er lette at forstå:
\nAdministrator-, servicekonti og produktionsadgang skal have skrappere kontrol. Kræv stærkere adgangskoder, MFA, begrænset adgang, overvågning og omgående rotation ved ændringer.
\nStærke adgangskoder kan ikke kompensere for for mange rettigheder. Brugere bør kun have adgang til de systemer og hemmeligheder, de har brug for i deres rolle.
\nDetekter usædvanlige loginmønstre, umulige rejseruter, gentagne fejlslagne forsøg, login fra nye lande og adgang uden for normal arbejdstid. Password-politikken bør understøttes af overvågning og beredskab for hændelser.
\nUndervisningen bør fokusere på genbrug af adgangskoder, phishing, falske login-sider, MFA-træthed, sikker deling og hvordan mistænkt kompromittering rapporteres. Undgå at bebrejde brugerne. Gør sikker adfærd let.
\nEn password-politik skal være forståelig. Hvis politikken er for lang, vag eller stram, vil folk omgå den. Den bedste politik er den, der faktisk kan håndhæves og følges.
\nBrug denne skabelon som udgangspunkt. Tilpas de [firkantede sektioner] så de passer til jeres organisation, systemer, risikoniveau og lovkrav.
\nPassword-politik\n\nVersion: [1.0]\nEjer: [Sikkerhed / IT-afdeling]\nIkrafttrædelsesdato: [ÅÅÅÅ-MM-DD]\nRevurderingscyklus: [Hver 12. måned]\n\n1. Formål\n\nDenne politik definerer kravene til oprettelse, brug, opbevaring, deling og ændring af adgangskoder for [Organisationens navn]. Formålet er at reducere risikoen for uautoriseret adgang, tyveri af legitimationsoplysninger, kontoovertagelse og datatab.\n\n2. Omfang\n\nDenne politik gælder for alle ansatte, konsulenter, midlertidigt ansatte, tjenesteudbydere og enhver anden, som får adgang til [Organisationens navn]s systemer, applikationer, netværk, cloud-tjenester eller data.\n\nPolitikken gælder for almindelige brugerkonti, privilegerede konti, servicekonti, delte konti og alle systemer, hvor adgangskoder benyttes til autentificering.\n\n3. Krav til oprettelse af adgangskoder\n\nAlle adgangskoder skal opfylde følgende krav:\n\n- Menneskelige brugerkonti skal benytte adgangskoder på mindst 16 tegn.\n- Adgangskoder skal være unikke og må ikke genbruges på arbejds- eller private konti.\n- Adgangskoder må ikke indeholde navne, brugernavne, virksomhedsnavne, fødselsdatoer, tastaturmønstre, gentagne tegn eller anden lettilgængelig information.\n- Adgangskoder må ikke være baseret på gængse sætninger, citater, sangtekster eller forudsigelige udskiftninger.\n- Adgangskoder må ikke fremgå af kendte brudte adgangskodelister eller almindeligt brugte adgangskodelister.\n- Adgangskoder må indeholde mellemrum, symboler, tal, store og små bogstaver.\n- Adgangssætninger er tilladt, hvis de er lange, unikke og ikke baseret på forudsigelige eller offentlige sætninger.\n\n4. Password managers\n\n[Organisationens navn] kræver eller anbefaler kraftigt brug af en godkendt password manager til oprettelse, opbevaring og deling af adgangskoder.\n\nBrugere må benytte adgangskodegenerator, autofyld og copy-paste fra den godkendte password manager. Brugere må ikke lagre adgangskoder i browsere, regneark, dokumenter, notes-apps, e-mail, chatbeskeder, skærmbilleder eller ikke-godkendte værktøjer.\n\n5. Multi-faktor autentificering\n\nMulti-faktor autentificering skal aktiveres, hvor det teknisk er muligt, herunder men ikke begrænset til:\n\n- E-mailkonti\n- Fjernadgangssystemer\n- Password manager-konti\n- Cloud-tjenester\n- Administrative konti\n- Økonomi-, HR- og andre højrisikosystemer\n- Alle systemer klassificeret som [fortrolige / kritiske]\n\nHvor det er muligt, skal brugere benytte phishing-resistent MFA såsom passkeys, hardware security keys eller platform authenticatorer. Authenticator-apps foretrækkes frem for SMS. SMS-baseret MFA er forbudt, hvis en anden MFA-metode er teknisk mulig og må kun anvendes, hvor ingen stærkere MFA-mulighed findes.\n\n6. Skift af adgangskoder\n\nAdgangskoder skal ændres straks når:\n\n- En adgangskode er kendt eller mistænkt for at være kompromitteret.\n- En bruger har indtastet adgangskoden på en mistænkt phishing-site.\n- En adgangskode er blevet delt med en ikke-autoriseret person.\n- Malware eller uautoriseret adgang detekteres på brugerens enhed.\n- En adgangskode optræder i et kendt data-brud.\n- En privilegeret brugers rolle eller ansættelsesstatus ændres.\n- IT eller Sikkerhed instruerer brugeren i at ændre adgangskoden.\n\nRutinemæssig udløb af adgangskoder er ikke krævet, medmindre det påbydes ved lov, kontrakt, regulativ eller systembegrænsning. Adgangskoder må ikke ændres ved små forudsigelige tilføjelser til tidligere adgangskoder.\n\n7. Deling af adgangskoder\n\nAdgangskoder må ikke deles via e-mail, chat, tickets, dokumenter, skærmbilleder, telefonopkald eller mundtlig kommunikation.\n\nDelte legitimationsoplysninger må kun benyttes, hvor individuelle konti ikke er teknisk mulige, eller når det eksplicit er godkendt af [Sikkerhed / IT]. Godkendte delte legitimationsoplysninger skal opbevares og deles via den godkendte password manager og adgangen skal begrænses til autoriserede brugere.\n\n8. Privilegerede konti\n\nPrivilegerede konti skal anvende unikke adgangskoder, der ikke bruges til nogen almindelig brugerkonto. Privilegerede konti skal benytte MFA hvor det teknisk er muligt og skal gennemgås regelmæssigt.\n\nPrivilegerede adgangskoder skal roteres, når en administrator forlader organisationen, skifter rolle, ikke længere har brug for adgang, eller ved mistanke om kompromittering.\n\n9. Servicekonti og applikationshemmeligheder\n\nServicekonto-adgangskoder, API-nøgler, tokens og applikationshemmeligheder skal opbevares i et godkendt system til hemmelighedshåndtering eller password manager.\n\nServicekonto-legitimationsoplysninger må ikke indlejres i kildekode, konfigurationsfiler, images, dokumentation eller scripts, medmindre beskyttet af en godkendt hemmelighedshåndteringsproces.\n\n10. Nulstilling af adgangskoder og kontogendannelse\n\nProcesser for nulstilling af adgangskoder skal verificere brugerens identitet, før adgangen gendannes. Nulstillingslinks og midlertidige adgangskoder skal være engangsbrug, udløbe hurtigt og sendes via godkendte kanaler.\n\nBrugere skal informeres, når deres adgangskode ændres eller nulstilles. Midlertidige adgangskoder skal skiftes ved første login.\n\n11. Tekniske kontrolforanstaltninger\n\nSystemer, der opbevarer eller behandler adgangskoder skal:\n\n- Aldrig opbevare adgangskoder i klartekst.\n- Hashe adgangskoder med en godkendt, moderne salted password hashing-algoritme: PBKDF2, scrypt, bcrypt eller Argon2.\n- Ikke benytte MD5, SHA-1, SHA-256, SHA-512 eller andre hurtige hash-algoritmer alene til adgangskode-hashing.\n- Beskytte autentificeringsendpoints med ratelimit eller tilsvarende kontrol.\n- Afvise almindelige, svage og kendte kompromitterede adgangskoder.\n- Tillade indsætning af adgangskoder fra password managers.\n- Understøtte rimelig adgangskodelængde, inkl. mindst 64 tegn hvor det teknisk er muligt.\n- Logge sikkerhedsrelevante autentificeringshændelser.\n\n12. Indberetning af mistænkt kompromittering\n\nBrugere skal straks indberette mistænkt adgangskodekompromittering, phishing, usædvanlige login-prompter, MFA-prompter, de ikke selv har aktiveret, eller utilsigtet adgangskode-afsløring til [Sikkerhed / IT-kontakt].\n\n13. Undtagelser\n\nUndtagelser fra denne politik skal dokumenteres, risikovurderes, tidsbegrænses og godkendes af [Sikkerhed / IT-ledelse]. Kompenserende foranstaltninger skal indføres, hvor det er muligt.\n\n14. Håndhævelse\n\nManglende overholdelse af denne politik kan medføre fjernelse af adgang, obligatorisk sikkerhedstræning, disciplinære foranstaltninger eller andre tiltag svarende til [Organisationens navn]s politikker og gældende lovgivning.\n\n15. Revision\n\nPolitikken skal revideres mindst årligt eller efter væsentlige ændringer i systemer, trusler, lovkrav eller forretningsdrift.\nEn stærk password-politik handler ikke om at gøre adgangskoder besværlige. Det handler om at fjerne dårlige vaner, understøtte password managers, bruge MFA og reagere hurtigt, når adgangsoplysninger bliver kompromitteret. Hold politikken praktisk, håndhævelig og fokuseret på reelle angreb som phishing, credential stuffing, genbrug af adgangskoder og kompromitterede konti.
","frontmatter":{"date":"May 07, 2026","slug":"password-policy-dos-donts-best-practices","title":"Password-politik: Do's, Don'ts, Best Practices og en Copy-Paste Skabelon","description":"Lær, hvad en moderne password-politik skal kræve, hvilke forældede regler du bør undgå, og kopier en praktisk skabelon for din organisation.","author":"Sascha Pfeiffer","featuredImage":null}}},"pageContext":{"slug":"password-policy-dos-donts-best-practices","lang":"da","langPathPrefix":"/da"}},"staticQueryHashes":["2149092236","3128451518","3192060438"]}