NIS2 og smart living: Hvad leverandører af intelligente boligløsninger skal vide om compliance i 2026

Hvis du leverer smart living-teknologi i 2026, er det ikke længere nok “bare” at have et sikkert produkt — du skal også kunne dokumentere din sikkerhed, dine leverandører og din beredskabsevne, fordi du kan være en del af en NIS2-reguleret leverandørkæde.

Artiklen giver dig et handlingsorienteret overblik over, hvordan NIS2 påvirker producenter, installatører og leverandører af intelligente bolig- og bygningsløsninger: hvordan du vurderer om du er direkte omfattet eller indirekte berørt, hvad ledelsen konkret hæfter for, hvad en risikovurdering bør indeholde, og hvilken dokumentation du skal kunne fremvise ved tilsyn. Du får også typiske faldgruber og praktiske næste skridt, uden at det bliver alarmistisk eller uoverskueligt.

Hvorfor NIS2 pludselig rammer smart living-leverandører

Smart living er blevet kritisk infrastruktur i miniature: adgangskontrol, varmestyring, ventilationsanlæg, energistyring, kameraer, sensorer og gateways er forbundet til netværk og cloud-tjenester — ofte med fjernsupport, apps og løbende firmwareopdateringer. Det gør løsningerne mere værdifulde, men også mere sårbare.

NIS2 (EU’s direktiv om cybersikkerhed) skærper kravene til risikostyring, hændelsesrapportering og ledelsesansvar for organisationer i kritiske og vigtige sektorer. Den korte definition er: NIS2 er et regelsæt, der kræver systematisk styring af cyberrisici — ikke kun i egne systemer, men også i leverandørkæden. Det betyder noget for smart living-segmentet, fordi mange leverer ind i bygninger og boligmiljøer, der ejes eller drives af NIS2-omfattede organisationer (fx energi, sundhed, digital infrastruktur, offentlige aktører og større ejendomsdrift).

I praksis ser jeg især tre drivere i markedet: (1) flere udbud og kontrakter kræver dokumenteret cybersikkerhed, (2) de første håndhævelsessager i EU har gjort leverandørstyring til et bestyrelsespunkt, og (3) angreb via leverandører og fjernadgang er blevet en af de mest realistiske trusselsveje i driftsmiljøer.

Er din virksomhed direkte omfattet — eller “bare” underleverandør?

Det reelle problem for mange mindre og mellemstore aktører er, at man ikke har kortlagt sin rolle. Nogle er direkte omfattet (typisk hvis man selv falder i en NIS2-sektor og har en vis størrelse), mens mange andre er indirekte berørt, fordi kunderne kræver NIS2-lignende kontroller i kontrakter og leverandørvurderinger.

Typiske tegn på direkte omfattethed

Du kan være tættere på direkte forpligtelser, hvis du eksempelvis:

• leverer digitale tjenester eller drift, der kan kategoriseres som digital infrastruktur (fx cloud, datacenter, managed services) til større kunder
• har en rolle som væsentlig serviceleverandør i en kritisk sektor (fx energistyring til netselskaber eller hospitalsbygninger)
• har en størrelse og markedsrolle, hvor myndigheder typisk vil forvente moden sikkerhedsstyring
• driver netværksinfrastruktur eller platforme, som andre er afhængige af i drift

Typiske tegn på indirekte påvirkning via leverandørkæden

Du er ofte indirekte berørt, hvis du leverer produkter eller ydelser, der giver adgang til kundens netværk eller data: gateways, remote management, installatørkonti, serviceportaler, API-integrationer, eller hvis din løsning indgår i bygningsautomation (BMS) og OT/IT-sammenkobling.

Den vigtigste sondring i 2026 er ikke “om NIS2 gælder for mig i teorien”, men om du kan bestå kundens leverandørkontrol. Mange oplever, at kravene kommer som spørgeskemaer, audit-klausuler, krav om beredskabsplaner og krav om dokumentation for patching, logning og adgangsstyring.

Ledelsens ansvar: det, der ændrer spillet for SMV’er

NIS2 gør cybersikkerhed til et ledelsesansvar, ikke et rent IT-anliggende. Det betyder, at direktion og bestyrelse forventes at kunne tage stilling til risici, prioritere ressourcer og følge op på, om kontroller virker i praksis. I leverandørkæder bliver det meget konkret: hvis en kunde spørger “hvem ejer risikoen?”, skal svaret ikke være en enkelt tekniker.

Hvad ledelsen bør kunne vise i praksis

• Godkendt risikoprofil for jeres produkter/tjenester (hvad kan gå galt, og hvad gør I ved det?)
• rolle- og ansvarsfordeling: hvem beslutter, hvem udfører, hvem kontrollerer
• prioriteret roadmap for sikkerhedstiltag (3–12 måneder), bundet op på forretningsmål
• rapportering: faste nøgletal (fx patch-tider, MFA-dækning, hændelser, leverandørstatus)

En praktisk tommelfingerregel

Hvis jeres løsning kan låse en dør op, slukke varmen, give adgang til en kamerastream eller åbne en VPN ind i kundens miljø, så skal ledelsen behandle det som en “driftskritisk” risiko — også selv om I er 15 ansatte og ikke har en CISO.

Hvad en NIS2-inspireret risikovurdering bør indeholde for smart living

En brugbar risikovurdering er ikke en 60-siders rapport. Den er et beslutningsværktøj, der kobler jeres teknologi og leverancemodel til realistiske trusler. For smart living er det ofte kombinationen af fysisk påvirkning og digital adgang, der gør konsekvensen højere end i klassisk kontor-IT.

Start med at kortlægge “hvad der er sandt” i jeres leverance: hvilke komponenter I har kontrol over, og hvilke der ligger hos underleverandører (cloud, push-notifikationer, identity, remote support, firmwarebiblioteker, installatør-apps).

1. Aktiver og dataflows: en enkel oversigt over enheder, apps, cloud, API’er, og hvor data og kommandoer flyder
2. Trusselsbillede: fx misbrug af fjernadgang, kompromitterede installatørkonti, supply chain-angreb via opdateringer, udnyttelse af kendte CVE’er i gateways
3. Sårbarheder og kontrolniveau: patching, hardening, segmentering, logging, MFA, nøglestyring, secure boot (hvis relevant)
4. Konsekvens: hvad sker der ved nedbrud eller kompromis? (sikkerhed, drift, økonomi, omdømme, kontraktbrud)
5. Sandsynlighed: baseret på eksponering (internetvendt?), kompleksitet og historik
6. Behandling: accepter, reducer, overfør (kontrakt/forsikring), eller undgå
7. Kontrol af leverandører: hvilke afhængigheder kan vælte jer, og hvilke krav stiller I til dem?

Et konkret eksempel: En producent af intelligente dørtelefoner tilbyder fjernsupport via en administratorkonsol. Hvis konsollen ikke kræver MFA, og hvis logning er begrænset, kan en kompromitteret installatørkonto blive en genvej til kundens netværk eller til at ændre adgangsregler. Risikobehandlingen kan være relativt lavpraktisk: MFA, rollebaseret adgang, tidsbegrænsede supporttokens, og en logpolitik der gør hændelser sporbare.

Leverandørstyring i praksis: sådan gør du det uden at drukne i skemaer

Leverandørstyring bliver ofte misforstået som “send et spørgeskema én gang om året”. I NIS2-kontekst handler det om at kende dine kritiske afhængigheder og have en plan, hvis de svigter. For smart living er de mest kritiske leverandører typisk cloud-hosting, identitetsplatforme, firmware/SDK-komponenter, installationspartnere og eventuelle SOC/overvågningstjenester.

Det er her, mange ender med at google sig frem til en tjekliste. Hvis du vil dykke dybere i, hvad kunder og tilsyn typisk forventer, kan du tage udgangspunkt i NIS2 krav og omsætte punkterne til jeres konkrete leverancemodel.

En pragmatisk leverandørmodel (3 niveauer)

• Niveau 1: Kritiske leverandører — hvis de fejler, stopper jeres service eller sikkerhed. Kræv dokumentation, auditret, hændelsesnotifikation og tydelige SLA’er.
• Niveau 2: Vigtige leverandører — påvirker kvalitet og drift, men kan erstattes. Kræv minimumskontroller og opdateret sikkerhedskontakt.
• Niveau 3: Standardleverandører — lav risiko. Hold det let: basisvilkår og registrering.

Hvad du realistisk kan kræve (og selv blive mødt med)

I 2026 er det almindeligt, at større kunder beder om dokumentation som ISO 27001-tiltag, SOC 2-rapporter eller tilsvarende kontroller. For SMV’er er det ofte mere realistisk at starte med “kontrolbeviser” frem for certificeringer: politikker, logudtræk, screenshots af MFA-dækning, patch-statistik, og en enkel oversigt over hændelseshåndtering. Det kan være nok til at komme igennem en leverandørvurdering, hvis det er konsistent og opdateret.

Beredskabsplaner og hændelser: det, kunderne spørger om først

“Har I en incident response plan?” er blevet et standardspørgsmål. Ikke fordi alle forventer et fuldt kriseberedskab som i en bank, men fordi fraværet af plan betyder, at en hændelse bliver dyrere og mere kaotisk — og at kunden ikke kan stole på jeres kommunikation.

Minimumsberedskab, der faktisk virker

• Kontaktliste og roller: hvem tager imod alarmer, hvem taler med kunder, hvem kan stoppe fjernadgang?
• Hændelseskriterier: hvornår er noget “en sikkerhedshændelse” hos jer (fx kompromitteret admin-konto, læk af nøgler, uautoriseret firmware)?
• Første 4 timer: konkrete handlinger (isolér, nulstil credentials, stop tokens, bevar logs)
• Kommunikationsskabeloner: kort status, påvirkning, afhjælpning, næste opdateringstidspunkt
• Øvelse: én tabletop-øvelse pr. år med et realistisk scenarie

Et godt scenarie for smart living er “kompromitteret installatørkonto med adgang til flere kunders miljøer”. Her tester du både tekniske kontroller (MFA, session management, logning) og din evne til at afgrænse påvirkning og informere hurtigt.

Dokumentation ved tilsyn eller kundeaudit: hvad du skal kunne fremvise

Dokumentation er ofte det, der adskiller “vi gør det” fra “vi kan bevise det”. Ved tilsyn eller leverandøraudit er det sjældent nok at henvise til gode intentioner. Du skal kunne vise, at sikkerhed er en proces med ejerskab og sporbarhed.

En praktisk dokumentationspakke kan bestå af:

1. System- og dataoverblik: arkitekturdiagram (simpelt), dataflows, afhængigheder
2. Politikker og procedurer: adgangsstyring, patching, backup, logning, ændringsstyring
3. Risikovurdering: seneste version + beslutninger (hvad er prioriteret, hvad er accepteret?)
4. Leverandøroversigt: kritikalitet, kontakt, krav, seneste evaluering
5. Beredskabsplan: incident response, kommunikation, læring efter hændelser
6. Kontrolbeviser: MFA-status, patch-rapporter, sårbarhedsscans, logeksempler, træningslog

Det lyder omfattende, men for mange kan det holdes på 15–30 sider plus bilag. Det vigtigste er, at det er opdateret og hænger sammen: hvis politikken siger “kritiske patches inden 14 dage”, skal du kunne vise, at det faktisk sker.

Hvad koster det at komme i gang — og hvordan holder du indsatsen nede?

Omkostningen afhænger af udgangspunkt og kompleksitet. Den største fejl er at tro, at compliance starter med et dyrt værktøj eller en certificering. For de fleste smart living-aktører er de første gevinster proces- og disciplinbaserede.

Som grov sammenligning: En lille virksomhed kan ofte etablere et fornuftigt baseline-program med 20–60 timers internt arbejde fordelt over 4–8 uger (kortlægning, politikker, risikovurdering, beredskab, leverandøroversigt) plus eventuel ekstern sparring. Hvis I har mange produkter, flere cloudmiljøer og mange installationspartnere, stiger indsatsen, men den kan stadig fases.

Hold omkostningen nede ved at:

• genbruge eksisterende driftsrutiner (change management, supportprocesser) og dokumentere dem
• vælge 5–10 nøgletal frem for 50 (fx MFA-dækning, patch-SLA, antal kritiske findings)
• starte med kritiske leverandører og internetvendte flader
• undgå “one-size-fits-all” skabeloner, der ikke matcher jeres arkitektur

Typiske faldgruber i 2026 — og hvordan du undgår dem

De mest almindelige problemer jeg ser i leverandørkæderne omkring smart living handler ikke om avanceret hacking, men om manglende overblik og uklare aftaler.

• Uklar rollefordeling: “Kunden patcher” vs. “leverandøren patcher”. Løsning: skriv det ind i kontrakt og driftshåndbog, inkl. tidsfrister.
• Shadow-remote access: fjernadgang oprettet til support og aldrig fjernet. Løsning: tidsbegrænset adgang, godkendelsesflow og logning.
• Installatørkonti uden styring: delte brugere, ingen MFA, ingen offboarding. Løsning: individuelle konti, MFA, og proces når en partner stopper.
• Firmware og komponenter uden SBOM-tankegang: man ved ikke, hvad der er i produktet. Løsning: begynd at føre komponentliste og track kendte sårbarheder.
• Dokumentation, der ikke kan holdes levende: store politikker, ingen ejerskab. Løsning: korte procedurer, fast review-kadence (fx kvartalsvis).
• Overfokus på papir: flotte dokumenter, men ingen logning eller test. Løsning: få de basale kontroller til at virke og gem beviser løbende.

Hvis du kun tager én ting med: få styr på adgangsstyring (MFA, roller, offboarding), patch- og sårbarhedshåndtering samt en simpel hændelsesproces. De tre områder går igen i næsten alle audits og i de fleste reelle hændelser.

De næste skridt: en enkel plan for de første 30 dage

Hvis du skal prioritere uden at skabe et compliance-projekt, der sluger alt, så brug en 30-dages plan med klare leverancer:

1. Dag 1–5: kortlæg j