Varför offentlig sektor behöver security.txt

Enligt Check Point Research var offentlig sektor den mest drabbade sektorn i studien, följt av telekom och hälso- och sjukvård.
→ Ransomware ökar – svenska organisationer utsattes för 1 845 attacker i veckan under oktober (Dagens infrastruktur, 2025)

Ransomwareangreppet mot IT-leverantören Miljödata i augusti 2025, som slog ut system hos omkring 200 kommuner och exponerade personuppgifter för över en miljon människor, blev en brutal påminnelse om hur sårbart det offentliga Sverige är.

I det här läget vi befinner oss i finns det en liten men betydelsefull åtgärd som inte tillräckligt många inom offentlig sektor har genomfört ännu. Den handlar om att publicera en enkel textfil på sin webbplats som talar om för omvärlden hur man vill bli kontaktad om någon upptäcker en säkerhetsbrist. Filen heter security.txt och den beskrivs i en internationell standard, RFC 9116, framtagen inom IETF.
→ RFC 9116: A File Format to Aid in Security Vulnerability Disclosure
→ security.txt
→ Därför ska du ha en security.txt på din webbplats (Webperf, 2021)

Jag vill med den här texten visa varför det är särskilt angeläget att just offentlig sektor tar den här standarden på allvar, vad den innebär rent praktiskt och hur kommuner och myndigheter själva kan ha nytta av den.

Jag kan redan nu avslöja att med mitt enkla test tycks bara 72% av svenska kommuner ha en security.txt, men att nästan alla som har en security.txt också har ett giltigt innehåll.

Vad är security.txt och hur fungerar den?

En security.txt är en liten textfil som placeras i katalogen /.well-known/ på en webbplats. Syftet är att på ett standardiserat och maskinläsbart sätt beskriva hur man vill bli kontaktad av den som hittar en säkerhetsbrist. Dessa brister kan upptäckas av säkerhetsforskare, en engagerad invånare eller helt enkelt någon som råkar snubbla över ett problem.

Filen innehåller ett antal fält. Två av dem är obligatoriska enligt standarden. Det första är Contact, som anger en e-postadress, ett telefonnummer eller en webbadress dit säkerhetsrelaterade rapporter ska skickas. Det andra är Expires, som anger ett datum då informationen i filen bör betraktas som inaktuell och behöver uppdateras.

Utöver det finns valfria fält.

• Preferred-Languages anger vilka språk organisationen kan ta emot rapporter på.
• Canonical anger var filen finns publicerad så att dess äkthet kan verifieras.
• Policy kan peka på en webbsida som beskriver organisationens regler för den som vill rapportera en brist.
• Encryption gör det möjligt att peka på en publik nyckel för krypterad kommunikation.
• Acknowledgments kan länka till en sida där organisationen tackar de som bidragit till att göra den säkrare.

Ett enkelt men fullgott exempel på en security.txt ser ut så här:

Contact: mailto:sakerhet@exempelkommun.se 
Preferred-Languages: sv, en 
Canonical: https://exempelkommun.se/.well-known/security.txt 
Expires: 2026-12-31T23:59:00+01:00

Det tar inte lång tid att skapa en sådan fil. Det kräver inte heller stora tekniska insatser eller investeringar. Att placera den på rätt plats och se till att den hålls uppdaterad är det viktigaste. Och förstås att någon tar emot eventuella mejl som kommer in.

Varför det spelar särskilt stor roll i offentlig sektor

Det finns flera skäl till att just kommuner, regioner och myndigheter bör prioritera att ha en korrekt security.txt på plats. Offentlig sektor hanterar stora mängder känsliga personuppgifter. Allt från personnummer och sjukvårdsdata till uppgifter om skyddade identiteter och socialtjänstärenden passerar genom offentliga system varje dag. Konsekvenserna av säkerhetsbrister som inte rapporteras i tid kan bli allvarliga, både för de individer vars uppgifter riskerar att exponeras och för förtroendet för den offentliga verksamheten i stort.

Offentliga aktörer har dessutom ett ansvar att vara föredömen. Att följa etablerade standarder och god praxis inom informationssäkerhet är inte bara en teknisk fråga utan handlar om regelefterlevnad och om att leva upp till de förväntningar som ställs på verksamheten.

Myndigheten för civilt försvar (MCF) har vid upprepade tillfällen konstaterat att alltför många offentliga organisationer saknar grundläggande förutsättningar för ett systematiskt cybersäkerhetsarbete. En security.txt ersätter förstås inte ett sådant arbete, men den signalerar en medvetenhet om att informationssäkerhet är en fråga som tas på allvar och blir en väg in för de som råkar hitta något som är problematiskt.

Ansvarsfull rapportering av säkerhetsbrister

Det handlar också om att möjliggöra ansvarsfull rapportering av brister, det som på engelska kallas responsible disclosure. Utan en tydlig kanal för att rapportera problem vet den som upptäcker en brist ofta inte vart den ska vända sig. Ska man ringa kommunens växel? Maila registrator? Vågar man alls höra av sig utan att riskera att anklagas för ett dataintrång?

I brist på ett enkelt och standardiserat sätt att nå rätt person eller funktion riskerar rapporter att falla mellan stolarna, att dröja eller att aldrig komma fram alls. I värsta fall väljer den som hittat bristen att inte rapportera något alls, och då är det i stället en illvillig aktör som till slut utnyttjar sårbarheten.

Standarden har brett internationellt stöd. Organisationer som Google, Facebook och GitHub har implementerat security.txt, och flera länders myndigheter rekommenderar aktivt att offentliga aktörer gör detsamma. Bland dessa finns brittiska, franska, italienska, nederländska och australiska myndigheter.

Hur kommunerna ligger till

För att få en bild av nuläget har jag granskat samtliga 290 svenska kommuners webbplatser för att se om de har en publicerad security.txt och om filens innehåll uppfyller de grundläggande kraven i standarden.

Så kommer du igång med en security.txt

Att skapa en security.txt är en av de enklaste åtgärderna en organisation kan vidta för att förbättra sin beredskap inom informationssäkerhet. Det behöver inte vara komplicerat och det behöver inte ta lång tid.

1. Det första steget är att bestämma en kontaktväg dit säkerhetsrelaterade rapporter ska skickas. Det bör vara en funktionsbrevlåda, inte en enskild persons e-postadress. Rapporter bör nå fram även vid semester och personalbyten. Något i stil med sakerhet@ eller security@ fungerar bra.
2. Det andra steget är att skapa själva filen med de obligatoriska fälten Contact och Expires, och gärna även Preferred-Languages och Canonical. Det finns ett enkelt verktyg på securitytxt.org som hjälper till att generera filen i rätt format.
3. Det tredje steget är att publicera filen under sökvägen /.well-known/security.txt på webbplatsen. Filen ska vara tillgänglig via HTTPS och ha innehållstypen text/plain.
4. Det fjärde och kanske viktigaste steget är att se till att filen hålls levande. Utgångsdatumet i Expires bör vara rimligt, kanske ett år framåt i tiden, och när det närmar sig behöver filen uppdateras. Det bör också finnas en intern rutin för att faktiskt bevaka och hantera de rapporter som kommer in via den angivna kontaktvägen.

Att ha en security.txt på plats är förstås inte en garanti mot cyberattacker. Men det är ett konkret uttryck för att organisationen vill göra rätt. Att organisationen välkomnar hjälp och att den följer den internationell praxis som finns för att underlätta ansvarsfull rapportering av säkerhetsbrister. Det är en mycket liten insats med potentiellt stora positiva effekter.
Och det är precis den sortens åtgärd som det offentliga Sverige behöver mer av.