NIS2 selger konsulenttimer om dagen. Det meste som skrives om direktivet retter seg mot virksomheter som faktisk omfattes. Denne teksten handler om de andre: det lille verkstedet, produsenten med tolv ansatte, underleverandøren. De faller utenfor loven, og får kravene i fanget likevel. Her er hvorfor, og hva som er verdt å gjøre nå.
Status i norsk rett per august 2026
Det er lett å blande sammen to lover som ligner. Kort oppsummert:
- Digitalsikkerhetsloven ble vedtatt 12. desember 2023 og trådte i kraft 1. oktober 2025. Den gjennomfører det første NIS-direktivet, og er en ren rammelov. Det materielle innholdet ligger i forskrift.
- NIS2 er ikke gjennomført i norsk rett. Direktivet er ennå ikke tatt inn i EØS-avtalen, og det finnes ingen bekreftet dato. Lovarbeidet pågår.
- EU-fristen for medlemsstatene var 17. oktober 2024. Norge ligger altså bak, og har gjort det siden.
Terskelverdiene følger EUs SMB-definisjon. Mellomstor virksomhet er 50 til 249 ansatte og 10 til 50 millioner euro i omsetning, eller 10 til 43 millioner euro i balanse. Stor virksomhet er 250 ansatte eller mer. Under det faller du som hovedregel utenfor, uansett sektor. Unntakene er få og spisse: enerådende leverandører av en kritisk tjeneste, DNS-tjenester, toppdomeneregistre, tillitstjenester og offentlige ekomnett.
Et verksted på Jæren med tjue ansatte omfattes ikke. Det er verdt å si tydelig, fordi mye av markedsføringen antyder noe annet.
Kravene kommer via kunden, ikke via loven
NIS2 stiller krav til sikkerhet i leverandørkjeden. En omfattet virksomhet må vurdere og dokumentere risikoen ved sine leverandører. Det er ikke en frivillig øvelse, og det er heller ikke noe de kan besvare på dine vegne.
Praktisk betyr det at spørreskjemaet lander hos underleverandøren. Det har allerede skjedd i årevis med personvern og med kvalitetsstyring, og mønsteret er identisk: den store aktøren dytter dokumentasjonskravet nedover. Det er den veien regelverket faktisk treffer små bedrifter i Norge.
Spørsmålene i et slikt skjema er nesten alltid de samme fire:
- Hvilke enheter finnes i nettverket deres?
- Hvem eier dem, og hvilke er kritiske for produksjonen?
- Hvordan oppdager dere at noe ukjent kobler seg til?
- Hvor lang tid tar det før dere ser at noe kritisk har forsvunnet?
Ingen av dem kan besvares fra hukommelsen, og ingen av dem løses av et policy-dokument. De løses av et inventar som oppdaterer seg selv.
Hvorfor regnearket alltid dør
Alle har prøvd regnearket. Det holder i tre måneder. Årsakene er tekniske, ikke et spørsmål om disiplin.
IP-adresse er ikke identitet. DHCP gjenbruker adresser, så en enhet som ble kastet i fjor står fortsatt oppført, mens den nye maskinen som fikk adressen ser ut som den gamle. Vertsnavn er nesten like ustabilt. MAC-adressen er eneste brukbare nøkkel, og selv den svikter når klienter randomiserer eller når maskinen sitter i en dokkingstasjon som eier MAC-en. Jeg har skrevet mer om nøkkelproblemet og produsentoppslaget tidligere.
Størrelsesordenen er beskjeden og likevel uhåndterbar manuelt. Mitt eget nett har 36 enheter. Et middels verksted jeg skanner regelmessig har 57. Det er langt mer enn noen holder i hodet, og langt mindre enn det som rettferdiggjør et enterprise-produkt.
To datalag: maskinen observerer, mennesket kuraterer
Dette er den viktigste designbeslutningen i hele modulen, og den som avgjør om noen gidder å bruke systemet etter måned to. Hver enhet har to sett felter, og skanningen har ingen kodevei inn i det andre settet.
const OBSERVED_FIELDS = [
'ip', 'mac', 'hostname', 'vendor', 'open_ports',
'mdns_services', 'dhcp_fingerprint', 'last_seen_at',
'uplink_switch', 'uplink_port',
];
const CURATED_FIELDS = [
'name', 'owner', 'location', 'is_critical',
'type_locked', 'notes',
];Ingest skriver kun det første settet. Navn, eier, plassering, kritisk-flagg og notater er menneskets, og en skanning kan fysisk ikke røre dem. Det finnes en test på nettopp den regelen, fordi den er lett å rive ned ved et uhell og umulig å oppdage etterpå.
Samme prinsipp gjelder berikelse fra andre kilder. Har kunden en managed kontroller, kan den gi deg svitsj og portnummer per enhet, altså et faktisk kabelkart. Men den kilden får bare berike enheter som allerede finnes. To kilder som begge kan opprette enheter gir duplikater fra dag én.
Første skann er grunnlinje, ikke funn
Da jeg satte modulen i drift hjemme, fikk jeg 34 varsler på dag én. Alle var «ny ukjent enhet», og alle var feil. Systemet hadde ingenting å sammenligne med.
Regelen ble: første kartlegging hos en kunde er grunnlinje og produserer null varsler. Etter grunnlinja er tallene plutselig meningsfulle. Hos verkstedet står det nå 7 åpne varsler, og alle 7 er ekte enheter som kom til etter kartleggingen.
Samme klasse feil dukket opp med dødmannsknappen. En nyregistrert skannekilde uten rapporter ble regnet som «stille» per definisjon, og varslet umiddelbart. Fristen måles nå fra da kilden ble opprettet. Modulen skal ikke rope før den har noe å sammenligne med.
Tersklene som fjerner de falske varslene
Fraværsvarsling er der slike systemer vanligvis mister tilliten. Fire regler har vist seg å holde:
- Skill maskinobservert tilstedeværelse fra menneskesatt status. Slår du dem sammen, kan du ikke skille «printeren er avslått i helgen» fra «printeren er fjernet». Dette er den vanligste modelleringsfeilen.
- Savnet krever tre sammenhengende tapte skann. Med 15-minutters intervall gir det rundt 45 minutter, borte etter et døgn, savnet etter en uke, arkivert etter en til to måneder. Aldri autoslett.
- Og at andre enheter på samme lokasjon ble sett i de samme skannene. Uten denne betingelsen varsler hele nettet hver gang skanneren mister strømmen.
- Kun enheter merket kritiske varsler ved fravær. Mobil, bærbar og alt med randomisert MAC varsler aldri. Enda bedre er å lære oppetidsandel per enhet over 30 dager og bare varsle når historisk tilgjengelighet ligger over 95 prosent. Da klassifiserer systemet selv en laptop som sporadisk, uten at noen må merke den.
Til sammenligning: Home Assistant bruker 180 sekunder som standard for consider_home, og praktisk anbefaling der ligger på 10 til 15 minutter. NetAlertX bruker 30 minutters sovetid. Tersklene er ikke magi, men de må være klasseavhengige.
Skanning uten å installere noe
Hos kunder er det sjelden mulig å installere en agent, og på en del bokser er det ikke engang mulig å legge igjen en fil. Løsningen som fungerer er at boksen som allerede står der henter skanneren ved behov, kjører den, og sender resultatet ut. Et parallelt ping-sveip av et /24 med etterfølgende lesing av nabotabellen målte 4,7 sekunder og fant 41 verter, godt innenfor en timeout på 120 sekunder.
# sveip, så les det kjernen allerede har lært
for i in $(seq 1 254); do ping -c1 -W1 192.168.2.$i &>/dev/null & done; wait
ip neigh show | grep -v FAILEDTo ting er verdt å vite på forhånd. Kjører boksen BusyBox, støtter ikke ip flagget -j, og en skanner som forutsetter JSON-utdata faller helt sammen. Tekstparsing må ligge der som fallback. Og et vanlig discovery-skann henter ingen porter i det hele tatt, så klassifiseringen må klare seg med produsent, vertsnavn og mDNS.
Adressene bør ha en plan før de har en historie
Et inventar blir dramatisk mer lesbart når adressene er delt i blokker. Planen jeg bruker på et /24 i produksjonsmiljø:
| Område | Bruk |
|---|---|
.1 | Gateway |
.2 til .9 | Kjerneswitcher |
.10 til .19 | Servere, NAS, husautomasjon |
.20 til .39 | Produksjonsmaskiner |
.40 til .59 | Aksesspunkter og småswitcher |
.60 til .79 | Printere og kontormaskiner |
.80 til .99 | Reserve |
.100 til .254 | DHCP-pool |
Metoden er DHCP-reservasjon, ikke statisk adresse satt på enheten. Alt ligger samlet i kontrolleren, adressen kan endres uten å røre maskinen, og gateway og DNS distribueres automatisk. Det siste er verdt mye på skjæreplottere og fresemaskiner med tungvinte menyer.
Ulempen er reell: en maskin som starter mens DHCP-serveren er nede får ingen adresse. I praksis betyr det lite, siden den da uansett ikke har noen å snakke med. Unntaket er maskiner som kun snakker med en PC på samme switch og aldri trenger gateway. Der er ekte statisk adresse tryggere.
Og en advarsel: å renummerere et eksisterende nett er høyere risiko enn gevinst. IP-adresser er hardkodet i RIP-programvare, i skjæreoppsett, i skannemapper mot NAS og i jobbfiler. Planen bør gjelde alt nytt utstyr, mens eksisterende maskiner flyttes bare når de likevel er nede. Rekkefølgen med lavest risiko først er nettverksutstyr, deretter printere, deretter NAS, og produksjonsmaskiner helt til slutt.
Det som faktisk er verdt å gjøre nå
NIS2 er ikke norsk lov ennå, og de fleste små virksomheter vil aldri omfattes direkte. Men det første spørsmålet i ethvert leverandørskjema er hva som finnes i nettverket, og det spørsmålet blir ikke enklere av å vente.
Kartlegg én gang, la det være grunnlinje, merk det som er kritisk, og la resten oppdatere seg selv. Den delen tar en ettermiddag. Policy-dokumentet kan skrives når noen faktisk spør etter det.
