Hvis du arbejder med smarthome, boligplatforme eller connected living, er der en reel risiko for, at din virksomhed i 2026 bliver mødt af NIS2-krav, uden at du nogensinde har kaldt dig “kritisk infrastruktur”.
I denne artikel får du en praksisnær guide til at vurdere, om din virksomhed kan falde ind under NIS2-direktivets anvendelsesområde, hvilke typiske “træk-ind” mekanismer der opstår via leverandørkæder i byggeri og drift, og hvad du konkret bør gøre, før du underskriver nye leverandøraftaler eller lancerer connected produkter. Du får også de mest almindelige faldgruber, et realistisk billede af omkostninger og en håndgribelig selvevaluering, der kan spare både juridiske og kommercielle konflikter.
Hvad er NIS2, og hvorfor rammer det pludselig bolig- og livsstilsbranchen?
NIS2 er EU’s opdaterede cybersikkerhedsdirektiv, der stiller krav til risikostyring, hændelsesrapportering og leverandørstyring for udvalgte sektorer. Pointen er enkel: når digitale tjenester eller netværks- og informationssystemer bliver samfundskritiske, skal sikkerhedsniveauet op, og ansvarskæden skal være tydelig.
Det nye i 2026-konteksten er, at bolig- og livsstilssektoren i stigende grad leverer digitale driftsfunktioner fremfor “bare” produkter. Et intelligent varmesystem er ikke længere en termostat; det er en cloud-forbundet styringsplatform, ofte med fjernadgang, app-login, firmwareopdateringer og integrationer til andre systemer (adgangskontrol, energistyring, alarmsystemer, betalingsløsninger). Når den type infrastruktur bliver en del af bygningers drift og sikkerhed, begynder NIS2 at være relevant.
Hvorfor mange smarthome-aktører fejlvurderer deres risiko
Den mest udbredte misforståelse er, at NIS2 “kun” gælder klassiske tech-virksomheder, energi, tele og store datacentre. I praksis opstår NIS2-relevans ofte gennem tre mønstre, jeg ser igen og igen i leverandørdialoger og compliance-gennemgange:
“Vi er jo bare en installatør” (men har fjernadgang og drift)
Installationsvirksomheder, integratorer og facility-partnere ender ofte med at have permanente serviceaftaler, remote management, admin-konti og ansvar for patching. Det flytter jer fra “håndværk” til digital driftsleverance. Hvis I samtidig arbejder for kunder, der selv er omfattet, bliver I hurtigt mødt af kontraktkrav, audits og sikkerhedsbilag.
“Vi sælger boligprodukter online” (men driver kritisk bruger- og betalingsinfrastruktur)
Bolig- og livsstilsplatforme kan være teknisk komplekse: marketplace-modeller, abonnementer, kundekonti, betalingsflows, retur- og logistikintegrationer, kundeserviceværktøjer og marketing automation. Det er ikke NIS2 i sig selv, men det kan gøre jer til en vigtig brik i en større leverandørkæde, hvor der stilles NIS2-lignende krav, fordi data, oppetid og hændelseshåndtering er forretningskritisk.
De afgørende kriterier: sektor, størrelse og “hvad I faktisk leverer”
NIS2 arbejder overordnet med to kategorier af organisationer: “væsentlige” og “vigtige” enheder, baseret på sektor og betydning. Dertil kommer størrelsestærskler, som ofte tager udgangspunkt i EU’s SME-definition (typisk medarbejderantal og omsætning/balance). Det er her mange går galt: de kigger kun på branchekode eller selvforståelse, ikke på funktion og leverance.
For smarthome og connected living er det sjældent sådan, at “smart home” står som en tydelig sektor i direktivet. I stedet bliver relevansen afledt af, om I leverer ydelser, der ligner eller understøtter sektorer, som er udtrykkeligt omfattet, eller om I bliver en kritisk leverandør til en omfattet enhed.
Størrelsestærskler: hvornår “for små til NIS2” ikke holder
Mange mellemstore aktører antager, at de automatisk er ude, hvis de er under en vis størrelse. Men to ting gør det usikkert at læne sig tilbage:
- Kontraktkrav kan ramme jer, selv hvis I ikke formelt er omfattet, fordi jeres kunder vil “nedarve” krav til leverandører.
- Vækst, opkøb eller nye service-modeller (fx 24/7 drift, managed services) kan flytte jer over tærsklen hurtigere end forventet.
Leverandørkæden: sådan bliver bolig- og smarthome-virksomheder trukket ind i scope
I praksis er leverandørkæden den store gamechanger. Når en bygherre, en kommune, et forsyningsselskab, et hospital eller en større ejendomsoperatør er omfattet, begynder de at kræve dokumentation for sikkerhed og hændelsesberedskab hos alle, der rører deres systemer.
Typiske kæder i byggeautomation og connected living
Her er eksempler på leverandørkæder, hvor NIS2-krav ofte “vandrer”:
- Bygherre/ejendomsoperatør → facility management → BMS/CTS-leverandør → smarthome-integrator → cloud-platform/SaaS
- Boligforening → adgangskontrolleverandør → installatør med remote support → underleverandør af IoT-gateways
- Nybyg-projekt → entreprenør → tekniske fagentrepriser → leverandør af intelligente varmesystemer → app- og backenddrift hos tredjepart
“Vi er bare underleverandør” er ikke et frikort
Selv når I ikke er direkte omfattet, kan I blive mødt af krav om sikkerhedsforanstaltninger, logning, sårbarhedshåndtering, incident response og dokumentation. Det skyldes, at NIS2 lægger vægt på styring af IKT-leverandørkæder og på, at omfattet virksomhed skal kunne vise, at deres leverandører ikke udgør en uacceptabel risiko.
Hvilke “kritiske funktioner” udløser typisk pligt i smarthome-kontekst?
Det, der i praksis gør en bolig- eller livsstilsaktør “kritisk”, handler sjældent om selve produktet, men om konsekvensen ved nedbrud eller kompromittering. Spørg jer selv: Hvad sker der, hvis vores systemer er nede i 24 timer? Hvad hvis en angriber får admin-adgang?
- Fjernstyring af varme, ventilation, adgang, låse, porte eller alarmer i større ejendomme
- Central platform til styring af mange enheder på tværs af lokationer (multi-tenant drift)
- Privilegeret adgang (admin-konti, servicekonti, API-nøgler) til kunders driftsmiljø
- Automatiseret opdatering af firmware/software, hvor kompromittering kan blive en “supply chain”-hændelse
- Identitets- og adgangsstyring for beboere/brugere (apps, digitale nøgler, gæsteadgang)
- Betalings- og abonnementsinfrastruktur, hvor brud kan give driftstab, svindel eller datalæk
Et konkret eksempel: En integrator, der drifter adgangskontrol i 20 større ejendomme via en cloud-konsol, kan blive mødt af krav om MFA, segmentering, logning, incident response og dokumenteret patching. Ikke fordi adgangskontrol “er NIS2”, men fordi kundens risikoprofil og driftskritikalitet gør det uacceptabelt at have svage led.
Praktisk selvevaluering: spørgsmålet, der afgør om I skal handle nu
Når jeg hjælper virksomheder i connected living med at afklare deres compliance-risiko, starter vi altid med samme kerne: er virksomheden omfattet af NIS2 som formel enhed, eller er I “kun” indirekte ramt via kontrakter og kundekrav? Begge scenarier kræver handling, men prioriteringen og dokumentationen bliver forskellig.
En 7-trins tjekliste, der fungerer i praksis
- Identificér jeres ydelser: installation, drift, support, platform, app, datahosting, overvågning.
- List jeres kundetyper: offentlige kunder, forsyning, større ejendomsdrift, sundhed, transport, finans, større byggeprojekter.
- Kortlæg systemadgang: har I remote access, admin-rettigheder, servicekonti, VPN, API-adgang?
- Vurder konsekvens: påvirker et nedbrud sikkerhed, adgang, varme/ventilation eller mange brugere samtidigt?
- Check størrelse og vækst: ligger I tæt på tærskler, eller forventer I markant vækst/opkøb?
- Gennemgå kontrakter: står der krav om incident notification, audits, sikkerhedsstandarder, logning, patching eller underleverandørstyring?
- Placér jer i en risikokategori: “formelt omfattet”, “indirekte omfattet via kunder”, eller “lav relevans lige nu”.
Hvilke dokumenter bør I kunne fremvise inden næste udbud eller rammeaftale?
- En kort sikkerhedspolitik og risikovurdering for jeres vigtigste systemer
- Incident response-proces (hvem gør hvad, hvornår, og hvordan eskaleres der?)
- Oversigt over kritiske leverandører (cloud, betalingsudbyder, logning, remote tools) og hvordan de vurderes
- Adgangsstyring: MFA, princip om mindst mulige rettigheder, offboarding
- Patch- og sårbarhedsstyring (inkl. tidsfrister og ansvar)
Hvad koster NIS2-arbejdet i praksis, og hvor opstår de skjulte omkostninger?
Omkostningerne afhænger af jeres modenhed og kompleksitet. For en typisk smarthome-aktør med 20–100 ansatte er de største poster sjældent “et dyrt værktøj”, men tid og koordinering: systemoverblik, procesdesign, leverandørdialoger, logning, adgangsstyring og hændelsesøvelser.
De skjulte omkostninger opstår ofte her:
- Uafklaret scope giver dobbeltarbejde: man implementerer kontroller, men kan ikke dokumentere dem
- Teknisk gæld i legacy-installationer: gamle gateways, delte admin-konti, manglende segmentering
- Leverandør-lock-in: cloud- eller remote tools uden tilstrækkelige sikkerheds- og auditmuligheder
- Hastværk op til kontraktunderskrift, hvor jurister og teknikere arbejder i blinde
Et nyttigt pejlemærke: Hvis jeres forretning bygger på drift og fjernadgang, bør I budgettere med, at sikkerheds- og compliance-arbejdet bliver en løbende driftsdisciplin på linje med kvalitet og arbejdsmiljø, ikke et engangsprojekt.
De klassiske faldgruber (og hvordan I undgår dem)
Faldgrube 1: At forveksle “ikke omfattet” med “ingen krav”
Selv uden formel omfattethed kan I blive mødt af NIS2-lignende krav i kontrakter, især hvis I leverer til større ejendomsdrift, forsyning eller offentlige kunder. Løsningen er at have et baseline-sikkerhedsniveau og standardbilag klar, så I ikke forhandler fra nul hver gang.
Faldgrube 2: At fokusere på papir fremfor drift
Policies uden implementering falder igennem ved audits og ved hændelser. Prioritér få, robuste kontroller: MFA overalt, logning af admin-handlinger, patching med deadlines, og en testet incident-proces.
Faldgrube 3: At overse underleverandører og “små” komponenter
En kompromitteret remote support-agent, et usikret IoT-gateway-image eller en delt API-nøgle kan være alt, der skal til. Sørg for at have styr på, hvem der har adgang til hvad, og hvordan nøgler/credentials roteres.
Bedste praksis i 2026: sådan gør I compliance til en konkurrencefordel
Markedet bevæger sig mod, at sikkerhed bliver et salgsparameter i bygge- og driftsprojekter. De virksomheder, der kan dokumentere modenhed, vinder ofte på lavere friktion i udbud, hurtigere onboarding og færre kundespecifikke særkrav.
- Standardisér jeres sikkerhedsbilag: én “supplier security pack” med kontroller, ansvar og kontaktpunkter
- Indfør secure-by-default i produkter: MFA, stærke standardindstillinger, logging, og tydelig opdateringspolitik
- Segmentér miljøer: adskil kunders installationer, og isolér administrative værktøjer
- Træn hændelser: én tabletop-øvelse pr. halvår gør en mærkbar forskel på responstid og kvalitet
- Gør leverandørstyring konkret: krav til cloud, remote tools og betalingsudbydere, inklusive hændelsesvarsling og ansvar
Hvis I arbejder med adgang, varme eller bygningsautomation, er det ofte mere overbevisende at vise konkrete kontroller (loguddrag, MFA-coverage, patch-SLA’er) end at sende lange politikdokumenter. Det er også her, dialogen med bygherrer og facility management typisk bliver konstruktiv: de vil se, at I kan styre risikoen i drift.
