I 2026 er det ikke længere kun el, vand og tele, der bliver mødt af skærpet cybersikkerhedstilsyn—smart home-branchen er pludselig med i samtalen, og mange opdager det for sent.
Hvis du producerer, installerer eller leverer connected home-løsninger, kan NIS2-direktivet ramme dig indirekte via kunder, partnere og forsyningskæder—eller direkte, hvis din teknologi bliver en del af kritiske tjenester. I denne artikel får du et handlingsorienteret overblik over, hvornår du reelt kan være omfattet, hvilke krav der typisk volder problemer i praksis, og hvordan du vurderer, om ekstern hjælp er nødvendig, når du ikke har dedikerede compliance-ressourcer.
Du får også konkrete eksempler fra smart living-virkeligheden: intelligente låse, energistyring, alarm- og adgangssystemer, cloud-platforme, gateways og serviceaftaler—og hvor NIS2 typisk “bider”.
Hvad er NIS2, og hvorfor angår det smart living i 2026?
NIS2 er EU’s direktiv om foranstaltninger til et højt fælles cybersikkerhedsniveau på tværs af Unionen. Kort sagt: det stiller krav til, hvordan organisationer styrer cyberrisici, håndterer hændelser, sikrer leverandørkæden og dokumenterer deres arbejde—med mulighed for tilsyn, påbud og sanktioner.
For smart home- og boligteknologi-segmentet er 2026 et vendepunkt, fordi markedet er blevet tættere koblet til kritisk infrastruktur: energinet (fleksibilitet og belastningsstyring), adgangskontrol i større ejendomme, integrerede sikkerhedssystemer og cloud-baserede driftsplatforme. Samtidig er tilsynsmyndighederne blevet mere modne i deres kontrolmetoder, og store kunder stiller mere konkrete krav end før—ikke kun “har I en politik?”, men “kan I bevise, at I kan modstå og håndtere et angreb?”.
Hvornår er en smart living-virksomhed reelt NIS2-pligtig?
Det spørgsmål fylder meget i branchen, fordi mange aktører ser sig selv som “produktleverandører” eller “installatører” snarere end som en del af kritiske tjenester. I praksis handler vurderingen om rolle, påvirkning og afhængigheder—ikke kun om, hvorvidt man selv ejer kritisk infrastruktur.
Direkte omfattet: når din ydelse er kritisk for en kritisk tjeneste
Du kan være direkte omfattet, hvis du leverer digitale tjenester eller drift, som er væsentlige for en NIS2-relevant enhed (fx energi, transport, sundhed, digital infrastruktur, vand, offentlig forvaltning m.fl.), og du selv falder i en kategori og størrelsesramme, der gør dig til “væsentlig” eller “vigtig” enhed efter national implementering. Eksempler i smart living-kontekst kan være:
- En cloud-platform, der styrer energiforbrug og fleksibilitet i stor skala (fx boligforeninger eller aggregator-samarbejder) og er integreret med energiselskabers processer.
- Adgangskontrol- og låsesystemer med central administration til kritiske lokationer (drift, vagt, logning, fjernåbning).
- Managed security/monitorering af integrerede alarmsystemer, hvor oppetid og incident response er kontraktkritisk.
Indirekte omfattet: når dine kunder kræver NIS2-lignende kontroller
Selv hvis du ikke er direkte NIS2-enhed, bliver du ofte “NIS2-pligtig i praksis” via kontrakter. NIS2 stiller eksplicit krav til leverandørkædesikkerhed, så dine kunder vil bede om dokumentation for alt fra adgangsstyring og sårbarhedshåndtering til hændelsesprocesser og underleverandørkontrol. I 2026 ser man især, at store kunder kræver:
- Dokumenteret risikostyring og sikkerhedspolitikker, der er omsat til drift.
- Bevis for patching, hardening og logning på gateways, hubs og management-porte.
- Styring af tredjepartssoftware, cloud og fjernsupport.
- Hændelsesberedskab med klare tidsfrister, ansvar og eskalation.
De typiske udfordringer i smart home-segmentet: scope, modenhed og ansvar
De fleste problemer opstår ikke, fordi virksomheder “ikke vil” sikkerhed, men fordi smart living-arkitekturer er komplekse: hardware + firmware + apps + cloud + installatørled + support + underleverandører. Når NIS2 skal oversættes til praksis, støder man ofte på fem klassiske knaster.
1) Afgrænsning af scope: hvad er egentlig “systemet”?
En intelligent lås er sjældent bare en lås. Den er en del af et økosystem: mobilapp, identitet, nøgleudstedelse, API’er, installatørportal, cloud-broker, logning og notifikationer. Hvis du kun “sikrer produktet”, men ignorerer driftsplatformen eller fjernsupporten, får du huller, der er lette at udnytte—og svære at forklare til et tilsyn eller en enterprise-kunde.
2) Teknisk og organisatorisk modenhed: man kan ikke dokumentere det, man ikke gør
Mange har gode intentioner, men mangler faste processer: hvem godkender ændringer, hvordan håndteres sårbarheder, hvor hurtigt patches, og hvad er minimumskrav til konfiguration hos installatører? NIS2 handler i høj grad om styring og gentagelighed—ikke enkeltstående initiativer.
Risikoidentifikation i praksis: sådan ser truslerne ud i connected home
Risikovurdering bliver hurtigt abstrakt, hvis den ikke tager udgangspunkt i konkrete angrebsscenarier. I smart home ser jeg typisk, at risikoen ligger i kombinationen af fjernadgang, mange enheder, lange levetider og uens opdateringsdisciplin.
- Fjernsupport og installatøradgange, der bliver “permanente” og sjældent recertificeres.
- Uens firmware-versioner og uklare patch-vinduer for enheder ude i felten.
- Svag identitets- og nøglestyring (fx delte admin-konti, manglende MFA).
- Cloud-afhængighed: hvad sker der ved outage, kompromittering eller misconfiguration?
- Supply chain-risici: SDK’er, open source-komponenter, underleverandørers build pipelines.
En god tommelfingerregel i 2026 er at koble risici til “hvad kan gå galt” i kundens virkelighed: kan en angriber låse døre op, slukke varme i en ejendom, deaktivere alarmer, eller udnytte din platform som springbræt ind i en større virksomheds netværk?
Dokumentationskrav: det, tilsyn og kunder faktisk spørger efter
En af de største overraskelser for smart living-virksomheder er, hvor meget NIS2 i praksis bliver et dokumentations- og beviskrav. Ikke i betydningen papir for papirens skyld, men fordi du skal kunne vise, at sikkerheden er styret og efterlevet.
Typiske artefakter, der bliver efterspurgt i 2026, kan samles i to spor: “styring” og “drift”.
- Risikoregister med prioritering, ejerskab og opfølgning.
- Politikker og standarder for adgangsstyring, logging, backup, sårbarheder og ændringer.
- Leverandørstyring: krav til underleverandører, vurderinger, kontraktbilag, opfølgning.
- Incident response-plan og øvelser: hvem gør hvad, hvornår, og hvordan kommunikeres der?
- Teknisk evidens: logudtræk, konfigurationsbaselines, patch-statistik, MFA-udrulning.
Faldgruben er at lave flotte dokumenter uden “spor” tilbage til virkeligheden. Hvis din installatørkanal i praksis kan omgå MFA, eller hvis sårbarheder håndteres ad hoc i Slack uden ticketing og SLA, vil det typisk blive opdaget i en moden kundeaudit.
Hvorfor generiske tjeklister ikke er nok—og hvad ekstern rådgivning konkret bidrager med
Der findes mange NIS2-tjeklister, men de fejler ofte på to punkter: de tager ikke højde for smart living-arkitekturens blanding af IT/OT/IoT, og de hjælper ikke med prioritering, når ressourcerne er knappe. Professionel ekstern hjælp handler derfor mindre om “at fortælle, hvad NIS2 siger” og mere om at oversætte krav til gennemførbare beslutninger.
Det er netop her, NIS2 rådgivning typisk gør en forskel for virksomheder, der har et stærkt produktteam, men ikke en fuldt bemandet compliance- og security-funktion.
Fra krav til designvalg: trade-offs der holder i drift
I smart home bliver sikkerhed ofte et spørgsmål om trade-offs: batterilevetid vs. kryptering, offline-funktionalitet vs. central kontrol, hurtig onboarding vs. stærk identitet. En erfaren rådgiver kan facilitere, at disse valg dokumenteres som risikobeslutninger, og at de bliver understøttet af kontroller, der kan driftes—fx minimumskrav til nøglehåndtering, secure update-mekanismer og adgangsmodeller for installatører.
Audit-klarhed: at kunne bevise det rigtige på den rigtige måde
Mange virksomheder bruger måneder på at “samle dokumentation”, men ender med at mangle netop de beviser, som kunder og tilsyn vægter: sporbarhed, ejerskab, og at kontroller er testet. Ekstern rådgivning bidrager ofte med skabeloner, ja, men vigtigere: en metode til at skabe en rød tråd fra risiko → kontrol → implementering → evidens.
Intern implementering: sådan forankrer du NIS2 uden at drukne organisationen
Det mest undervurderede i NIS2-arbejdet er implementeringen i hverdagen. Smart living-virksomheder er ofte projekt- og leverancedrevne, og sikkerhed kan ende som “noget vi gør bagefter”. I 2026 er det en dyr strategi, fordi hændelser og auditkrav rammer midt i leverancerne.
Organisér arbejdet omkring tre faste rytmer
- Månedlig sårbarhedscyklus: triage, prioritering, patch-plan, kommunikation til kunder/installatører.
- Kvartalsvis risikoreview: opdatering af risikoregister, ændringer i arkitektur og leverandører.
- Halvårlige øvelser: incident response tabletop og teknisk restore-test af backup.
Gør installatør- og partnerleddet til en del af kontrollen
Hvis du sælger gennem installatører eller partnere, skal dine kontroller også leve der. Det betyder typisk: standardiserede konfigurationsprofiler, tvungen MFA, rollebaseret adgang, tidsbegrænsede supportadgange og minimumskrav til, hvordan nøgler, QR-koder eller provisioning-data håndteres. En hyppig fejl er at antage, at “partneren har styr på det”—uden at du kan dokumentere krav, onboarding og løbende opfølgning.
Hvad koster NIS2-arbejdet, og hvordan prioriterer man rigtigt i 2026?
Omkostningerne varierer voldsomt efter kompleksitet og modenhed. For en mindre smart home-leverandør kan den første strukturerede indsats typisk ligge i spændet fra nogle få ugers fokuseret arbejde til flere måneder, hvis der mangler grundlæggende styring, asset-overblik og leverandørkontrol. Det dyreste er næsten altid ikke værktøjer, men tid: at få udvikling, drift, support og salg til at arbejde efter samme sikkerhedsmodel.
I 2026 giver det sjældent mening at starte med “alt på én gang”. En pragmatisk prioritering, der ofte holder i audit og i drift, er:
- Scope og asset-overblik: systemgrænser, dataflows, kritiske afhængigheder, “crown jewels”.
- Identitet og adgang: MFA, mindst privilegium, installatørstyring, logning af admin-aktiviteter.
- Sårbarhed og patch: SLA’er, firmware- og cloud-releaseprocesser, SBOM hvor relevant.
- Incident readiness: alarmering, eskalation, kontaktpunkter, øvelser og restore-test.
- Leverandørkæde: kontraktkrav, risikovurderinger, opfølgning på cloud og komponentleverandører.
Faldgruben er at investere i et GRC-værktøj eller en “compliance-platform” før man har besluttet, hvilke processer og minimumskrav der faktisk skal køre. Start med arbejdsgange og ansvar, og værktøjsunderstøt derefter.
De mest almindelige fejl smart living-virksomheder begår—og hvordan du undgår dem
- At undervurdere leverandørkæden: Hvis din cloud, push-notifikationer eller identitetsprovider fejler, fejler din tjeneste. Lav klare krav og løbende kontrol.
- At fokusere på politikker frem for drift: Dokumenter uden evidens bliver hurtigt en belastning i audits.
- At glemme feltet: Enheder lever længe, og “senere opdaterer vi” bliver til permanent teknisk gæld. Planlæg lifecycle og end-of-support.
- At gøre incident response til en PDF: Øv det, mål det, og test restore. Ellers virker det ikke under pres.
- At lade installatøradgange flyde: Brug tidsbegrænsede rettigheder, stærk autentifikation og sporbarhed.
En praktisk måde at teste din egen parathed er at stille dig selv tre spørgsmål: Kan vi på 48 timer få et sandt overblik over, hvilke kunder/enheder der er påvirket af en kritisk sårbarhed? Kan vi bevise, hvem der havde admin-adgang i sidste måned? Kan vi gendanne en central service fra backup inden for en aftalt tid? Hvis svaret er “måske”, er der et konkret implementeringsgab—uanset hvad der står i dine dokumenter.
