Hvis jeres smart home-løsning kan styre døre, varme, ventilation eller adgangskontrol, er I ikke “bare” en tech-virksomhed længere—i myndighedernes øjne er I en del af kritisk digital infrastruktur.
Denne artikel giver en praktisk, sektorrelevant guide til, hvordan smart living-, bygningsautomations- og IoT-virksomheder kan arbejde struktureret med NIS2: fra første risikovurdering til dokumentation, der kan tåle både kunders due diligence og myndigheders kontrol. Du får konkrete greb til leverandørstyring i en fragmenteret IoT-forsyningskæde, awareness-træning af teknikere i marken, incident response med 24/72-timers notifikation og ledelsesrapportering, der oversætter tekniske risici til forretningssprog.
Tonen er bevidst operationel: hvad man faktisk skal gøre, hvilke faldgruber der typisk vælter projektet, og hvad det realistisk koster i tid og ressourcer at komme i mål.
Hvad NIS2 er, og hvorfor smart living-sektoren rammes hårdere i 2026
NIS2-direktivet er EU’s opdaterede cybersikkerhedslovgivning, der skærper kravene til dokumenteret risikostyring, sikkerhedsforanstaltninger og hændelsesrapportering for et bredere udsnit af sektorer—samt for dele af deres leverandørkæder. Kort sagt: NIS2 handler ikke om “mere IT-sikkerhed” som en teknisk øvelse, men om, at virksomheden kan bevise, at den styrer cyberrisici systematisk.
Smart home- og boligteknologi rammes ofte indirekte først: I leverer komponenter, gateways, cloud-tjenester, apps, installationsydelser eller drift til kunder, der selv er omfattet. Når jeres kunde bliver målt på leverandørkæderisiko, bliver I det også. I 2026 ser vi typisk, at kravene flytter sig fra “kan I udfylde et sikkerhedsskema?” til “kan I dokumentere kontroller, hændelsesberedskab og modenhed over tid?”.
Den praktiske konsekvens er, at compliance ikke kan behandles som et IT-anliggende alene. Feltteknikere, indkøb, produktudvikling, drift, kundeservice og ledelse skal arbejde efter samme sikkerhedsmodel—ellers falder I på dokumentation, leverandørstyring eller reaktionstid ved hændelser.
De syv operationelle søjler: en model der kan implementeres i virkeligheden
Mange NIS2-initiativer fejler, fordi de starter med politikker i Word, men mangler en rød tråd til drift, produkter og leverandører. En mere robust tilgang er at organisere arbejdet i syv søjler, der kan planlægges, testes og revideres:
- Politikker og procedurer (styring, scope, ansvar, bevis)
- Tekniske sikkerhedstiltag (netværk, identitet, logging, hardening)
- Patch management og sårbarhedshåndtering for embedded/IoT
- Leverandørstyring i hardware- og softwareforsyningskæden
- Medarbejderbevidsthed (især installatører og teknikere)
- Hændelsesberedskab og myndighedsnotifikation (24/72 timer)
- Ledelsesrapportering og modenhedsmåling
Det vigtige er ikke, om jeres organisation kalder det “ISMS”, “GRC” eller “NIS2-program”, men at I kan vise sammenhæng: risici → kontroller → evidens → forbedringer. For smart living-virksomheder betyder det typisk, at produkt- og leverancekæden (fra firmware til montørbesøg) bliver en del af compliance-rygraden.
1) Politikker og procedurer, der faktisk kan bruges i en installations- og produktvirksomhed
Politikker er kun værdifulde, hvis de kan omsættes til beslutninger og adfærd. I smart home- og bygningsautomation ser jeg ofte to yderpunkter: enten meget generiske politikker (ingen effekt), eller ekstremt detaljerede dokumenter (ingen efterlevelse). Målet er “minimum viable governance”: klare regler, tydelige roller, og en dokumentpakke, der kan vedligeholdes.
Start med scope og ansvar, ikke med skabeloner
Et realistisk første skridt er at definere, hvilke tjenester og produkter der er i scope: cloud-platform, mobilapp, gateway/edge-enheder, installationsprocesser, remote support, firmware pipeline og eventuel drift/overvågning. Udpeg derefter ejerskab: hvem godkender risici, hvem ejer leverandørkrav, hvem kan stoppe en release ved kritiske sårbarheder.
Evidensdesign: beslut allerede nu, hvad I skal kunne bevise
Myndigheder og større kunder spørger sjældent “har I en politik?”. De spørger “hvordan ved I, at den følges?”. Indbyg derfor evidens i processen: change logs, godkendelser, patch-rapporter, træningskvitteringer, leverandørvurderinger, incident tickets og øvelsesreferater. Dokumentation er et biprodukt af god drift—ikke en separat disciplin.
2) Tekniske kontroller i IoT og bygningsautomation: segmentering, identitet og logging
Smart living-løsninger lever ofte i miljøer, hvor “IT” og “OT-lignende” drift blandes: trådløse sensorer, gateways, BACnet/Modbus-integrationer, cloud-styring og fjernsupport. Det giver angrebsflader, som klassiske kontor-IT-kontroller ikke dækker alene.
Netværkssegmentering, der passer til virkelige installationer
Segmentering handler ikke kun om VLAN-diagrammer. For installatører betyder det konkrete regler: hvilke enheder må tale med hvad, hvilke porte er nødvendige, og hvordan isolerer man gæstenet, beboernet og driftsnet. Et praktisk mønster er at definere tre zoner: “device/field”, “gateway/edge” og “cloud/management”, og så dokumentere godkendte flows imellem dem. Hvis I ikke kan beskrive normale dataflows, kan I heller ikke opdage unormale.
Patch management og hardening af embedded systemer
Patch management i IoT er vanskeligere end på laptops: lange levetider, begrænset storage, risiko for “bricking”, og kunder der ikke ønsker nedetid. Alligevel forventes en styret proces. Et pragmatisk setup inkluderer:
- En fast cadence (fx månedlig) for vurdering af nye sårbarheder og leverandørpatches
- En risikobaseret prioritering (kritiske CVE’er først, eksponering vurderes)
- Testmiljø der matcher typiske kundekonfigurationer
- Rollback-plan og dokumenteret release-godkendelse
- Kommunikationsskabeloner til kunder (hvad ændres, hvornår, risiko ved ikke at opdatere)
Faldgruben er at love “automatiske opdateringer” uden at have styr på signering, nøglehåndtering og fail-safe mekanismer. En enkelt fejl i en OTA-proces kan blive en driftshændelse i hundredevis af bygninger.
3) Leverandørstyring i en fragmenteret IoT-forsyningskæde (hardware, firmware, cloud og installatører)
Smart home-produkter er sjældent “jeres” hele vejen ned: SoC-leverandør, RTOS, open source-biblioteker, ODM/EMS-produktion, mobil SDK’er, cloud hosting, push-notifikationer, og underleverandører til installation eller service. NIS2 lægger vægt på styring af disse afhængigheder, fordi angreb ofte kommer via svage led.
Midt i arbejdet med at få styr på krav, kontroller og bevisførelse giver det mening at samle jeres indsats i en struktureret NIS2 implementering, hvor leverandørkrav, risikovurderinger og tekniske kontroller hænger sammen fra indkøb til drift.
Gør leverandørkrav målbare: fra “sikkerhed” til konkrete leverancer
“Leverandøren skal have passende sikkerhed” er ikke et krav—det er en hensigtserklæring. Bed i stedet om konkrete artefakter og processer, fx SBOM (software bill of materials), sårbarhedsproces, patch-SLA, secure boot/firmware-signering, og dokumentation for adgangsstyring til build-miljøer. Det, I ikke kan få ind som kontraktkrav, ender som jeres driftsrisiko.
Praktisk due diligence for mindre leverandører
Mange i økosystemet er små: specialiserede installatører, nicheproducenter, app-bureauer. Her virker en “tiered model” bedre end tunge audits:
- Tier 1 (kritiske): adgang til prod, firmware, cloud eller nøglekomponenter → dyb vurdering, kontraktkrav, årlige reviews
- Tier 2 (vigtige): leverer komponenter med moderat risiko → standard spørgeskema + stikprøvedokumentation
- Tier 3 (lav): ingen adgang til følsomme systemer → basis-krav og onboarding
Typisk fejl: at vurdere leverandører én gang og lægge rapporten i en mappe. I IoT ændrer komponenter sig hurtigt; opdater leverandørstatus ved større releases, nye integrationer eller ændret hosting.
4) Awareness-træning for teknikere i marken: der hvor sikkerheden ofte tabes
Feltteknikere og installatører er en af de mest oversete risikofaktorer i smart living. De håndterer ofte admin-adgange, lokale netværk, default credentials, fysisk adgang til kontrolbokse og kundedialog. En stærk sikkerhedspolitik hjælper ikke, hvis praksis i marken er “vi gør som vi plejer”.
Det mest effektive er korte, rollebaserede læringsforløb med konkrete scenarier, fx:
- Håndtering af adgangskoder og MFA ved kundebesøg (ingen delte konti)
- Hvad man gør, når kunden beder om “bare at åbne en port” i firewall
- Sikker brug af remote support-værktøjer og logning af sessioner
- Genkendelse af social engineering mod teknikere (”jeg er fra driften, kan du…”)
- Håndtering af USB/firmware-filer og verifikation af signaturer
Faldgruben er at køre e-learning én gang om året og kalde det done. Bedre praksis er microtræning hver 4–6 uge og korte “toolbox talks” før større udrulninger. Træning skal kunne ses i adfærd: færre delte konti, bedre ticket-noter, færre ad hoc-ændringer hos kunder.
5) Hændelsesberedskab: 24/72-timers frister og konkrete responsplaner
NIS2 stiller krav til hurtig rapportering og håndtering af væsentlige hændelser. For IoT- og bygningsautomation er udfordringen ofte at afgøre, hvornår noget er “væsentligt”: er det et lokalt udfald hos én kunde, en sårbarhed i en udbredt komponent, eller tegn på kompromittering på tværs?
Byg en responsplan, der matcher jeres arkitektur
En brugbar incident response-plan er ikke en generisk PDF. Den skal afspejle jeres stack: cloud, device management, firmware pipeline, mobile apps, kundesupport og installatørled. Sørg for, at planen indeholder:
- Triagering: hvem vurderer alvor, og efter hvilke kriterier
- Tekniske playbooks: fx kompromitteret device-certifikat, lækket API-nøgle, sårbar 3.-parts SDK
- Kommunikation: kunder, partnere, interne teams
- Bevis og logdata: hvad skal samles ind, og hvor længe opbevares det
- Beslutning om notifikation: hvem kan trykke på knappen
Øv notifikation og beslutningsflow—ikke kun teknik
24/72-timers vinduet falder ofte på beslutningsprocessen, ikke på selve afhjælpningen. Øv derfor “tabletop”-scenarier, hvor ledelse, jura, drift og support deltager: Hvilke data har vi? Hvad ved vi ikke? Hvad siger vi til kunder? Hvornår eskalerer vi til myndigheder? En øvelse der afslører uklare roller, er billigere end en hændelse der gør det.
6) Ledelsesrapportering: oversæt tekniske risici til forretningssprog
NIS2 lægger vægt på ledelsens ansvar. I praksis betyder det, at ledelsen skal kunne forstå og styre cyberrisiko som en forretningsrisiko: driftstab, kontraktbrud, produktansvar, omdømme og leveranceevne. Den største faldgrube er rapporter, der enten er for tekniske (ingen beslutninger) eller for fluffy (ingen realitet).
En god ledelsesrapport for smart living kan fx indeholde 8–12 KPI’er/KRI’er, der kan følges månedligt eller kvartalsvist:
- Patch compliance på gateways og kritiske komponenter (fx % opdateret inden for 30 dage)
- Antal kritiske sårbarheder i backlog og median tid til afhjælpning
- Andel leverandører i Tier 1 med opdateret vurdering og kontraktkrav
- Antal sikkerhedshændelser og near-misses, inkl. root cause-kategorier
- Træningsdækning for teknikere og resultater fra korte tests
- Logdækning/telemetri: hvor stor del af flåden rapporterer sikkerhedsrelevante events
Det afgørende er, at tallene kan føre til handling: investere i bedre device management, ændre leverandørkrav, prioritere hardening i næste release, eller justere installationsprocedurer. Hvis rapporteringen ikke ændrer beslutninger, er den kun pynt.
7) Fra første risikovurdering til løbende modenhedsmåling: en realistisk plan og hvad det koster
Spørgsmålet “hvad koster NIS2?” giver kun mening, hvis man skelner mellem engangsindsats (etablering) og løbende drift. For en mellemstor smart living-virksomhed er den typiske tidslinje 3–9 måneder til et “audit-klar” grundniveau, afhængigt af kompleksitet, antal produkter og leverandører, og hvor meget der allerede er på plads.
En realistisk plan kan se sådan ud:
- 0–4 uger: scope, gap-analyse, risikovurdering og prioriteret roadmap
- 1–3 måneder: minimum governance (politikker, roller, evidens), incident response og basis leverandørmodel
- 3–6 måneder: tekniske kontroller, patch/firmware proces, logging/monitorering, træningsprogram for teknikere
- 6–9 måneder: øvelser, modenhedsmåling, forbedringsloop og dokumentpakke til kunder/myndigheder
Omkostningsmæssigt ligger den store post sjældent i dokumenter, men i at få drift og produktudvikling til at arbejde mere forudsigeligt: bedre asset-overblik, automatiseret patch-udrulning, sikker build-pipeline, og tid til leverandørdialog. Mange undervurderer også tidsforbruget i marken: nye installationsstandarder kan kræve ekstra minutter per installation—gange hundredevis af sager bliver det til en reel driftsomkostning, som bør planlægges.
Typiske fejl, der gør implementeringen dyrere end nødvendigt:
- At starte med compliance-tekst før risikobilledet er klart
- At overse underleverandører og “skjulte” komponenter (SDK’er, push-tjen
