Hver Palo Alto-enhet som er tatt i bruk uten at krypteringsnøkkelen er byttet, lagrer nettverkets hemmeligheter kryptert med en nøkkel som er identisk hos alle kunder i hele verden. Palo Alto Networks skriver det selv, ordrett: «The default master key is publicly known and poses a critical security risk.»
Nøkkelen, kalt Master Key, beskytter alt som ligger lagret i konfigurasjonen: private nøkler til sertifikater, LDAP bind-passord, RADIUS- og TACACS+-secrets, IPSec pre-shared keys, passord for administratorer og tjenestekontoer, og interne SSH-nøkler. I praksis alt som gir tilgang videre inn i nettverket.
Dette er ikke en sårbarhet som krever et angrep. Det krever en fil. En konfigurasjonsfil ligger i backuper, sendes til leverandører ved feilsøking, og kan hentes ut av enhver med administrativ tilgang til enheten. Så lenge standard Master Key står, er en slik fil en lesbar kopi av virksomhetens hemmeligheter for den som får tak i den.
Fristen som gjør dette til en sak nå
Fra PAN-OS 12.2.2 har Palo Alto gjort standardnøkkelen til en håndhevet feiltilstand. En 60-dagers frist starter automatisk idet systemet oppdager at standardnøkkelen er i bruk. Tre hendelser utløser nedtellingen: oppgradering til 12.2.2 eller nyere, tilbakestilling til fabrikkinnstillinger, eller første oppstart av en ny enhet.
Fristen kan utvides til maksimalt 120 dager, men utvidelsen virker ikke slik de fleste antar. De 120 dagene regnes fra den utløsende hendelsen, ikke fra dagen utvidelsen settes. Palo Alto skriver det uttrykkelig: utvidelsen «does not add a new window from the date you configure it». Har det gått 60 dager siden oppgraderingen, får dere altså 60 dager til — ikke 120. Utvidelsen må dessuten konfigureres før den løpende fristen er ute. Settes ingen verdi, er fristen 60 dager.
Nedtellingen lar seg heller ikke nullstille ved å gå tilbake. Oppgradering eller nedgradering mellom 12.2.2 og nyere versjoner starter ikke klokken på nytt. Er fristen allerede utløpt og dere nedgraderer, feiler commit umiddelbart på den nedgraderte versjonen også.
Når fristen løper ut, blokkeres alle ordinære konfigurasjonsendringer, commit-all-jobber og HA-synkronisering. Auto-commits og dynamiske oppdateringer, inkludert innhold og antivirus, fortsetter som normalt. Enheten slutter altså ikke å beskytte trafikk. Men driften mister evnen til å endre noe som helst, og det er en tilstand ingen vil oppdage midt i en hendelse.
Det praktiske svaret på «står klokken og går hos oss?» finnes allerede i loggene. I hele fristperioden skriver enheten en systemlogg med kritisk alvorlighetsgrad ved hver eneste commit, og dialogen viser dagene som gjenstår. Dere trenger ikke et prosjekt for å finne ut om dette gjelder dere — dere trenger et søk i systemloggen.
Kjører dere en eldre PAN-OS-versjon, finnes ingen håndhevet frist. Risikoen er den samme. Standardnøkkelen har vært offentlig kjent hele tiden, og enheter på eldre versjoner logger den samme kritiske hendelsen uten å blokkere noe. Det som endrer seg ved oppgradering, er ikke risikoen. Det er at leverandøren slutter å la dere ignorere den. Å utsette oppgraderingen utsetter fristen, ikke eksponeringen.
Standardnøkkelen treffer krav virksomheten allerede måles på: NSMs grunnprinsipper (2.7.1 om kryptografistrategi og 2.3.7 om sikker konfigurasjon), CIS Controls 4.1 og 4.2 (grunnivået IG1), og ISO 27001 Annex A.8.24 og A.8.13. Det direkte treffet er NSM 2.7.1 og ISO A.8.24, som gjelder nøkkelforvaltning spesifikt, og som krever mer enn selve byttet: en dokumentert strategi for oppbevaring, sikkerhetskopiering, fornyelse og håndtering av kompromittering. NSM 2.3.7 gjelder strengt tatt standardpassord, ikke standard krypteringsnøkler, men det er det nærmeste vi kommer en av grunnprinsippene.
NIS2 kommer i tillegg, men er ennå ikke norsk rett — direktivet er ikke tatt inn i EØS-avtalen, og digitalsikkerhetsloven fra 1. oktober 2025 gjennomfører NIS1. Når NIS2 innføres, er artikkel 21(2)(h) om «policies and procedures regarding the use of cryptography and, where appropriate, encryption» punktet nøkkelforvaltningen rapporteres under. Virkeområdet utvides samtidig fra rundt 600 norske virksomheter til rundt 5 000. Den som planlegger nøkkelforvaltningen nå, slipper å gjøre arbeidet to ganger.
Hva et gjennomført bytte oppnår
Fra en rotasjon nLogic gjennomførte i august 2026 hos en norsk virksomhet med Palo Alto-brannmurer i datasenter og på distribuerte lokasjoner, styrt fra Panorama i høytilgjengelighet: hele porteføljen ble gjort ferdig samme morgen, uten driftsavbrudd og uten at én enhet feilet. Enhetene sluttet å logge den kritiske sikkerhetsadvarselen om standardnøkkelen, og nye konfigurasjonsfiler ble verdiløse for alle utenom virksomheten selv. Vi anbefaler likevel å dele arbeidet over to vedlikeholdsvinduer med en arbeidsdag imellom, av grunner den tekniske gjennomgangen forklarer nærmere. Selve nøkkelbyttet tar minutter per enhet, det er resynkroniseringen og verifiseringen etterpå som tar tid.
Hva byttet ikke fikser
To ting er ledelsesbeslutninger, ikke tekniske konsekvenser av byttet. For det første: hemmeligheter som allerede har vært eksponert i årevis blir ikke tryggere av at nøkkelen byttes i dag. En risikobasert vurdering av om disse skal roteres separat hører med i samme sak, og velger virksomheten å ikke rotere dem, er det en akseptert restrisiko som bør dokumenteres. For det andre: gamle konfigurasjonseksporter forblir lesbare med standardnøkkelen for alltid, og bør behandles som sensitive uansett hvor de oppbevares.
Det å bytte nøkkelen fjerner heller ikke risiko, det flytter den. Etter byttet er den nye nøkkelen eneste vei inn til konfigurasjonen. Mistes den, må enheten nullstilles til fabrikkinnstillinger og bygges opp på nytt, uten gjenopprettingsmulighet og uten hjelp fra leverandøren. Derfor er nøkkelforvaltningen selve leveransen, ikke nøkkelbyttet i seg selv. Tre lag bør stå: nøklene i et passordhvelv med en verifisert tilgangsliste, forseglede papirkopier i safe uavhengig av hvelvet, og en oppfølgingssak med reell frist i et system noen faktisk følger med på.
Hva dette krever av virksomheten
Et prosjekt av denne typen innebærer typisk to vedlikeholdsvinduer pluss en pilotkjøring, uten forventet tjenestepåvirkning siden byttet skjer i styringsplanet. Det krever minst fire navngitte personer med tilgang til nøklene, hvorav minst to interne. Ledelsen må ta stilling til en endring uten rollback-mulighet, signere restrisikoen ved delt nøkkel på enkelte enheter, beslutte om allerede eksponerte hemmeligheter skal roteres, og utpeke en eier av rotasjonsfristen. nLogic anbefaler også ti års nøkkellevetid på selve enheten mot Palo Altos anbefalte to, et bevisst og begrunnet avvik som bør risikovurderes og godkjennes skriftlig.
Tre spørsmål til IT-avdelingen
Hvilken PAN-OS-versjon kjører vi, og hvor mange av enhetene våre står fortsatt på standardnøkkelen? Dette kan driftsleder svare på samme dag, uten å endre noe. Hvis vi bytter i morgen: hvem kan hente ut nøkkelen, og logges det? Og: hvem eier fristen for neste rotasjon, og i hvilket system står den? Finnes den bare i et dokument, finnes den ikke i praksis.
Last ned den tekniske gjennomføringsveiledningen, SA-2026-08-08, med CLI-kommandoer, sjekklister og feilhåndtering ved å trykke på lenken under og fylle ut litt informasjon.
Artikkel 2 – teknisk del
Kilder
Alle lenker verifisert 21. august 2026.
Palo Alto Networks
- Manage the Master Key from Panorama — Panorama Administrator’s Guide. Kilden til sitatet om at standardnøkkelen er offentlig kjent, og til reglene for 60- og 120-dagersfristen. Oppdatert 30.07.2026
- Configure a Master Key — NGFW Administration. Levetid, påminnelse og leverandørens toårsanbefaling. Oppdatert 18.08.2026
- Is there a way to recover a lost Master Key? — KB kA10g000000PLwECAW. «A Master Key cannot be recovered. A factory reset must be performed to restore the default Master Key.»
Rammeverk og regelverk
- NSMs grunnprinsipper for IKT-sikkerhet v2.1 — 2.7 Beskytt data i ro og i transitt — tiltak 2.7.1 om strategi for håndtering av kryptografi. Anbefaling, ikke krav
- NSMs grunnprinsipper for IKT-sikkerhet v2.1 — 2.3 Ivareta en sikker konfigurasjon — tiltak 2.3.4 og 2.3.7. Merk at 2.3.7 gjelder standardpassord, ikke standard krypteringsnøkler
- CIS Controls Navigator v8.1 — Safeguard 4.1 og 4.2 (IG1)
- Digitalsikkerhetsloven — lov 20.12.2023 nr. 108, i kraft 1. oktober 2025. Gjennomfører NIS1, og er det som gjelder i norsk rett i dag
- NIS2-direktivet (EU) 2022/2555, artikkel 21(2)(h) — ennå ikke tatt inn i EØS-avtalen og ikke gjennomført i norsk rett
- ISO/IEC 27001:2022 Annex A — A.8.24 Use of cryptography og A.8.13 Information backup. Standarden er ikke fritt tilgjengelig; kjøpes fra Standard Norge
Ta kontakt for mer informasjon
