21. september 2026 vil statusen til FIPS 140-2-validerte kryptografiske moduler endres når de flyttes til NISTs historiske liste. OpenSSL understreker at datoen ikke automatisk ugyldiggjør eksisterende installasjoner. Samtidig nærmer det seg en annen viktig frist: OpenSSL 3.0 vil nå slutten av sin vanlige livssyklus 7. september 2026.
For bedrifter og organisasjoner som bruker OpenSSL I sikkerhetskritiske eller regulerte miljøer betyr september to viktige endringer å vurdere.
Det første gjelder OpenSSL 3.0, som når slutten av levetiden den 7. september 2026.
Det andre gjelder FIPS 140-2, der valideringene gjaldt 21. september 2026 er flyttet til den historiske listen i det amerikanske NIST Cryptographic Module Validation Program, CMVP.
OpenSSL understreker imidlertid at overgangen ikke skal tolkes som at alle eksisterende FIPS 140-2-baserte systemer plutselig blir ugyldige.
FIPS 140-2 vil ikke forsvinne over natten
FIPS 140 er en amerikansk sikkerhetsstandard for kryptografiske moduler og har stor betydning i blant annet offentlig sektor, forsvar, finans og andre virksomheter med høye krav til informasjonssikkerhet og samsvar med regelverk.
Når en FIPS 140-2-validering flyttes til den historiske listen 21. september, betyr ikke det at sertifikatet blir tilbakekalt.
Eksisterende systemer som bruker en tidligere validert kryptografisk modul trenger derfor ikke automatisk å bli tatt ut av drift på grunn av endringen.
For allerede distribuerte og autoriserte miljøer kan fortsatt bruk være mulig avhengig av organisasjonens regulatoriske krav, risikovurdering og reglene som gjelder for den nåværende driften.
Situasjonen er imidlertid annerledes for nye systemer, anskaffelser og sikkerhetsgodkjenninger. Der, FIPS 140-3 standarden som organisasjoner må følge når aktiv FIPS-validering er nødvendig.
OpenSSL har allerede gått over til FIPS 140-3
For organisasjoner som bruker OpenSSL, finnes det allerede en validert løsning for den nye standarden.
OpenSSL FIPS-leverandør 3.1.2 er validert i henhold til FIPS 140-3 gjennom NISTs og den kanadiske CSEs felles program for validering av kryptografiske moduler.
Valideringen har CMVP-sertifikatnummer 4985 og er gyldig til 10. mars 2030.
I følge OpenSSL kan den FIPS-validerte leverandøren brukes med flere versjoner innenfor OpenSSL 3.x-serien.
Dette betyr at organisasjoner kan planlegge overgangen til FIPS 140-3 uten nødvendigvis å måtte behandle endringen som en fullstendig erstatning av hele kryptografisk infrastruktur.
For store organisasjoner kan dette være betydelig. En migrering i regulerte miljøer innebærer ofte mye mer enn å installere en ny programvareversjon.

OpenSSL 3.0 når slutten av levetiden 7. september
FIPS-endringen er imidlertid ikke det eneste viktige problemet for OpenSSL-brukere i september.
De 7. september 2026 når OpenSSL 3.0 slutten av sin normale livssyklus.
Etter endt levetid bør ikke organisasjoner forvente regelmessige sikkerhetsoppdateringer for versjonen innenfor den normale støttesyklusen.
Dette betyr at selskaper som fortsatt bruker OpenSSL 3.0 må skille mellom to separate problemer:
Programvarelivssyklus og støtte, som er påvirket av at OpenSSL 3.0 når slutten av levetiden.
FIPS-validering, som omhandler hvilken kryptografisk modul som brukes og hvilken status den har i CMVP.
Det faktum at en FIPS-validering fortsatt kan være relevant for et eksisterende system, betyr ikke automatisk at den underliggende OpenSSL-versjonen skal fortsette å brukes etter at støtteperioden er over.
OpenSSL 3.5 er LTS-versjonen
For organisasjoner som planlegger sin langsiktige OpenSSL-strategi, OpenSSL 3.5 spesielt relevant.
Versjonen er en langsiktig støtteversjon, LTS, med en lengre planlagt støtteperiode.
Dette betyr at selskaper som fortsatt bruker eldre OpenSSL-versjoner, kanskje må se den kommende FIPS-endringen som en del av en større modernisering av sin kryptografiske infrastruktur.
I stedet for å bare migrere fra FIPS 140-2 til FIPS 140-3, kan organisasjoner samtidig evaluere hvilken OpenSSL-versjon som vil ligge til grunn for infrastrukturen deres i årene som kommer.
Den største utfordringen kan være valideringen rundt
Selve den tekniske oppgraderingen trenger ikke å være den mest tidkrevende delen av arbeidet.
I regulerte operasjoner kan en endring i kryptografiske komponenter også påvirke dokumentasjon, sikkerhetsarkitektur, internkontroll, testing, risikovurderinger og eksterne godkjenninger.
Det kan også være avhengigheter i applikasjoner, operativsystemer, nettverksprodukter, sikkerhetsplattformer og andre systemer der OpenSSL brukt indirekte.
Organisasjoner bør derfor ikke bare sjekke hvilke OpenSSL-versjoner som er installert direkte på servere.
De må også kartlegge hvor OpenSSL og FIPS-validerte komponenter brukes som en del av større produkter og plattformer.
Fire spørsmål IT-organisasjoner bør stille seg nå
Før september bør bedrifter og myndigheter fremfor alt få et klart bilde av sitt nåværende miljø.
Hvor brukes OpenSSL 3.0?
Systemer som fortsatt er avhengige av versjonen må identifiseres før utløpet av levetiden 7. september.
Hvor brukes FIPS 140-2-validerte moduler?
Dette gjelder både direkte installasjoner og kryptografiske komponenter som er inkludert i andre systemer.
Hvilke miljøer krever aktiv FIPS 140-3-validering?
Kravene kan variere mellom eksisterende systemer, nye installasjoner, anskaffelser og fremtidige prosjekter.
Hvor lang tid tar organisasjonens egen godkjenningsprosess?
I regulerte operasjoner kan testing, dokumentasjon og sikkerhetsgjennomganger ta betydelig lengre tid enn selve oppgraderingen.
Ingen harde grenser, men et tydelig skifte
OpenSSLs budskap er at 21. september ikke bør betraktes som en dag da all FIPS 140-2-basert infrastruktur plutselig må stenges ned.
Men endringen markerer fortsatt et klart skifte.
FIPS 140-3 er den nye generasjonen av standarden, mens eldre OpenSSL-versjoner gradvis forlater sine vanlige støtteperioder.
For IT-ledere, sikkerhetsansvarlige, systemeiere og organisasjoner med regulatoriske krav er problemet derfor større enn én enkelt dato i september.
Det handler om å sørge for at den kryptografiske infrastrukturen er støttet, validert og bærekraftig selv for fremtidige systemer og sikkerhetskrav.
Organisasjoner som fortsatt er avhengige av OpenSSL 3.0 eller FIPS 140-2 har derfor grunn til å inventarisere miljøene sine nå, prioritere berørte systemer og lage en klar plan for overgangen til et moderne og fortsatt støttet OpenSSL-miljø.
