Den smarte lås, du monterer i weekenden, eller den energistyring, din virksomhed sælger til rækkehuse, er ikke “bare” elektronik længere — det er software, netværk og produktansvar i samme pakke.
I 2026 er EU’s cybersikkerhedskrav for tilsluttede produkter blevet konkrete og håndgribelige: Du kan som forbruger forvente bedre sikkerhedsopdateringer og mere gennemsigtighed, og du kan som mindre producent ikke længere nøjes med “vi patcher, når vi har tid”. I denne artikel får du et praktisk overblik over, hvad reglerne betyder i smart living-markedet: hvilke produktkategorier der er omfattet, hvilke krav der gælder til dokumentation og support-perioder, og hvordan ansvar fordeles mellem producent, importør og distributør.
Hvad betyder Cyber Resilience Act i praksis for smart living?
Cyber Resilience Act (CRA) er EU-regler, der stiller bindende cybersikkerhedskrav til digitale produkter med netværksforbindelse gennem hele deres livscyklus — fra design og udvikling til support, sårbarhedshåndtering og teknisk dokumentation. Det betyder noget, fordi hjemmets IoT-enheder ofte står tændt 24/7, har adgang til privatlivsfølsomme data (kamera, mikrofon, sensorer) og kan fungere som springbræt til resten af hjemmenetværket.
For forbrugere handler CRA i praksis om at kunne stille et enkelt spørgsmål: “Hvor længe bliver det her produkt holdt sikkert?” For virksomheder handler det om at kunne dokumentere, at man har styr på secure-by-design, opdateringer, sårbarheder og hændelser — og at CE-mærkning ikke kun er en fysisk label, men også et compliance-arbejde, der kan auditeres.
Hvilke produkter i hjemmet er typisk omfattet?
Hvis et produkt kan kommunikere via Wi‑Fi, Bluetooth, Zigbee, Z‑Wave, Thread, Ethernet eller mobilnet og har software, der kan opdateres (eller burde kunne), er det i praksis i risikozonen for at være omfattet. Smart living-segmentet er derfor centralt.
Typiske smart home-kategorier, der rammes direkte
- Smarte låse, dørklokker og adgangskontrol (inkl. apps og gateways)
- Overvågningskameraer, babyalarmer og sensorer med cloud-adgang
- Routere, mesh-systemer og smart home-hubs
- Smarte termostater, varmepumpestyring og energistyringssystemer
- Tilsluttede hvidevarer: vaskemaskiner, ovne, køleskabe, robotstøvsugere
- Smart belysning og hjemmeautomatisering (kontakter, relæer, controllere)
Produkter, der ofte overses af mindre producenter
I min erfaring er det ikke de “klassiske” kameraer og låse, der giver flest compliance-overraskelser, men de produkter, der virker harmløse: en simpel gateway til energimåling, en app der styrer et relæ, eller en OEM-enhed med tilpasset firmware. Hvis din løsning består af flere dele (enhed + app + cloud), skal sikkerheden tænkes som et samlet produktøkosystem, ikke tre separate leverancer.
De vigtigste krav: sikkerhed som standard, opdateringer og sårbarhedshåndtering
CRA flytter cybersikkerhed fra “best effort” til forventet minimumsniveau. Det er ikke nok at sige, at man bruger kryptering; man skal kunne vise, hvordan man har reduceret kendte risici og kan reagere, når nye sårbarheder dukker op.
Secure-by-design og secure-by-default
For smart home betyder det typisk, at standardopsætning ikke må være usikker: ingen hårdkodede standardkoder, ingen åbne debug-porte i produktion, og ingen unødvendige tjenester eksponeret på netværket. Et konkret eksempel: Hvis en smart hub leveres med en webadmin på lokalnettet, bør den være slukket som standard, kræve stærk autentifikation og være beskyttet mod brute force.
Sårbarheder og patches som en driftdisciplin
Den nye normal er, at sårbarheder ikke er undtagelsen, men en del af produktets liv. Det kræver en proces: triage, prioritering, patch, test, udrulning og kommunikation. For en mindre producent kan det lyde tungt, men det kan operationaliseres med enkle byggesten: en SBOM (software bill of materials), en sikker opdateringsmekanisme og et tydeligt “security.txt”/kontaktpunkt til sårbarhedsrapporter.
Dokumentation og CE-mærkning: “papirarbejdet”, der beskytter både køber og producent
CE-mærkning i 2026 handler i stigende grad om at kunne fremvise teknisk dokumentation, der viser, at produktet lever op til relevante krav. For cybersikkerhed betyder det, at du skal kunne forklare designvalg, trusselsmodellering, test og hvordan du håndterer sårbarheder efter lancering.
Hvis du vil dykke ned i rammerne, kravtyperne og den praktiske compliance-oversættelse til produktudvikling, kan du læse mere om Cyber Resilience Act og bruge det som checkliste til at spotte huller i både dokumentation og processer.
Hvad “teknisk dokumentation” typisk bør indeholde
- Produktbeskrivelse og arkitektur (enhed, app, cloud, tredjepartstjenester)
- Trusselsmodel og risikovurdering (hvad kan gå galt, og hvordan reduceres det?)
- SBOM og afhængigheder (biblioteker, open source, versioner)
- Sikkerhedstest og resultater (fx sårbarhedsscanning, penetrationstest, fuzzing)
- Opdaterings- og patchproces (signering, rollback, fail-safe)
- Plan for sårbarhedsrapportering og håndtering (SLA’er, kommunikation)
Support-perioder og opdateringsløfter: hvad kan forbrugeren forvente?
Forbrugere har længe oplevet “smarte” produkter, der bliver dumme efter få år: cloud-lukninger, apps der ikke længere opdateres, eller enheder der står tilbage med kendte sikkerhedshuller. CRA presser markedet mod mere realistiske løfter og bedre forbrugerbeskyttelse, fordi sikkerhedsopdateringer og sårbarhedshåndtering bliver en del af produktansvaret.
Som køber bør du i 2026 vænne dig til at spørge efter supportperiode og opdateringspolitik før køb, især for produkter der har adgang til hjemmet (låse), privatliv (kamera) eller kritisk drift (varme/energi). En praktisk tommelfingerregel: Jo mere kritisk funktionen er, jo mindre acceptabelt er det med uklare opdateringsløfter.
Konkrete spørgsmål, der afslører modenhed
- Hvor længe leveres sikkerhedsopdateringer, og gælder det både enhed, app og cloud?
- Hvordan modtager jeg opdateringer — automatisk, manuelt, eller via en hub?
- Hvad sker der, hvis cloud-tjenesten lukker: virker basisfunktioner lokalt?
- Har produktet en offentlig proces for sårbarhedsrapportering (kontaktpunkt, respons-tider)?
- Er der kendte tredjepartsafhængigheder (fx chipset/SDK), og hvordan patches de?
Ansvarsfordeling i 2026: producent, importør og distributør
En af de største misforståelser i smart living-forsyningskæder er troen på, at “compliance ligger hos fabrikken i Asien” eller “det er importørens problem”. I praksis er ansvaret fordelt, og flere led kan blive ramt, hvis et produkt mangler dokumentation, opdateringer eller korrekt håndtering af sårbarheder.
Producentens typiske ansvar
Producenten (eller den, der markedsfører produktet under eget navn) skal sikre, at produktet er designet og udviklet efter kravene, at der findes teknisk dokumentation, og at der er en fungerende proces for opdateringer og sårbarhedshåndtering. Hvis du er en mindre virksomhed, der rebrander en OEM-enhed med egen app, er du i praksis ofte “producent” i compliance-forstand, fordi du kontrollerer softwareoplevelsen og markedsføringen.
Importør og distributør: kontrolpligt og sporbarhed
Importører og distributører har typisk en kontrolpligt: de må ikke bringe produkter på markedet, hvis der er klare tegn på manglende compliance. Det betyder, at en webshop eller en B2B-distributør i stigende grad bør kunne efterspørge dokumentation, opdateringspolitik og kontaktpunkt for sikkerhedshændelser. Sporbarhed (hvem leverede hvad, hvornår, og hvilken version) bliver vigtigere, fordi sårbarheder ofte er versionsspecifikke.
Hvad koster compliance for små producenter — og hvad koster det ikke at gøre det?
Spørgsmålet “hvad koster det?” er legitimt, især for mindre producenter i smart living, hvor marginer kan være pressede. Omkostningen afhænger mindre af virksomhedens størrelse og mere af, hvor sent man starter. Hvis sikkerhed først bliver et “projekt” efter lancering, bliver det dyrt: arkitekturændringer, manglende logning, usikre opdateringsmekanismer og uoverskuelige afhængigheder.
Som grov sammenligning fra praksis: At etablere en basal sårbarhedsproces og SBOM tidligt kan ofte gøres med få dages til få ugers arbejde (afhængigt af kompleksitet), mens reparation af en usikker opdateringskanal eller en dårlig nøglehåndtering kan kræve måneders redesign, recertificering og kundekommunikation. Dertil kommer den “usynlige” pris ved ikke at gøre det: flere support-sager, højere returprocent, dårligere anmeldelser og i værste fald tilbagetrækning fra markedet.
Typiske faldgruber i smart home-sikkerhed (og hvordan du undgår dem)
De fleste sikkerhedsfejl i smart living skyldes ikke én stor “hacker-fejl”, men mange små beslutninger, der tilsammen skaber et angrebsrum. Her er de mønstre, jeg oftest ser gå igen, når mindre teams skal skalere fra prototype til CE-klar vare.
- Uklare opdateringsløfter: Skriv en konkret opdateringspolitik, og hold den i produktets UI og på produktsiden.
- Ingen ejer af sårbarheder: Udpeg en ansvarlig (og en backup) for triage og koordinering, også i ferier.
- Afhængigheder uden overblik: Byg og vedligehold en SBOM; få styr på chipset-SDK’er og tredjepartsbiblioteker.
- Usikker onboarding: Sørg for sikker parring, unik identitet pr. enhed og beskyttelse mod “device takeover”.
- Cloud som single point of failure: Overvej lokal fallback for kritiske funktioner (fx varme og lås).
- Logning uden privatliv: Log nok til fejlsøgning og hændelser, men undgå at opsamle mere persondata end nødvendigt.
Handlingsplan: sådan kommer du i gang som køber eller virksomhed
CRA gør markedet mere modent, men det kræver også mere af både købere og leverandører. Som forbruger kan du bruge kravene som løftestang til at vælge produkter, der ikke bliver forældede sikkerhedsmæssigt. Som mindre producent kan du omsætte kravene til en håndterbar plan, der passer til et lille team.
Hvis du køber smart home i 2026
- Prioritér produkter med tydelig supportperiode og dokumenteret opdateringshistorik.
- Vælg leverandører, der beskriver sårbarhedsrapportering og har en offentlig sikkerhedskontakt.
- Undgå produkter, der kræver cloud for basisfunktioner, hvis funktionen er kritisk.
- Spørg til, om enheden kan isoleres på gæstenet/VLAN, og om den fungerer uden “åbne porte”.
Hvis du udvikler eller sælger smart living-produkter
- Indfør secure-by-design i kravspecifikationer: autentifikation, kryptering, nøglehåndtering, hardening.
- Etabler en opdateringspipeline med signering, versionsstyring og rollback-strategi.
- Lav SBOM og en fast cadence for scanning og patching af afhængigheder.
- Opsæt en sårbarhedsproces: intake, triage, rettelse, release-notes og kundekommunikation.
- Samle teknisk dokumentation løbende, så CE-arbejdet ikke bliver et panikprojekt til sidst.