Hvis du sælger smarte lamper, kameraer, låse eller IoT-aktiverede hvidevarer i EU i 2026, er “cybersikkerhed” ikke længere et salgsargument — det er et markedsadgangskrav. EU’s Cyber Resilience Act (CRA) rammer direkte de connected home-produkter, som bolig- og indretningsbranchen i stigende grad bygger løsninger og forretningsmodeller på.
Artiklen giver dig et praktisk overblik over, hvad CRA betyder i hverdagen for producenter, importører og integratorer: hvordan I kortlægger risici allerede i designfasen, hvilken teknisk dokumentation der skal være på plads ved markedsføring, hvordan sårbarhedshåndtering og softwareopdateringer skal organiseres gennem hele produktets levetid, og hvordan ansvar skal fordeles fra udvikling til direktion. Undervejs får du konkrete faldgruber, eksempler og en handlingsliste, så I kan komme i gang nu.
Hvad er Cyber Resilience Act — og hvorfor betyder den noget for smart home?
Cyber Resilience Act er en EU-forordning, der stiller fælles cybersikkerhedskrav til “produkter med digitale elementer” — altså hardware og software, der kan forbindes direkte eller indirekte til et netværk eller en anden enhed. Kort sagt: CRA flytter cybersikkerhed fra “best effort” til juridisk forpligtelse for hele værdikæden.
For bolig- og indretningssegmentet er det især relevant, fordi mange produkter i kategorien “connected home” er præcis den type udstyr, CRA er designet til at regulere: smarte pærer og gateways, sikkerhedskameraer, intelligente låsesystemer, termostater, robotstøvsugere og hvidevarer med app-styring. Når produkterne kobles på hjemmenetværk, cloud-tjenester og mobile apps, bliver de en del af kundens sikkerhedsperimeter — og dermed et attraktivt mål for angreb.
Det praktiske skifte for mange virksomheder er, at CRA ikke kun handler om “at undgå at blive hacket”. Den kræver, at I kan dokumentere, at I arbejder systematisk med sikkerhed: fra kravspecifikation og design til drift, sårbarhedshåndtering og opdateringer.
Hvem rammes: producent, importør, brand-owner eller integrator?
En typisk udfordring i branchen er, at ansvaret er fordelt på mange hænder: et brand i EU, en ODM/OEM i Asien, en app-udvikler, en cloud-leverandør og en dansk integrator, der sælger løsningen som del af en boligpakke. CRA gør det nødvendigt at få rollerne på plads, fordi krav og ansvar følger den, der bringer produktet i omsætning i EU.
Producenten (og “den der sætter sit navn på”)
Hvis I fremstiller produktet, eller markedsfører det under eget navn/varemærke, er I typisk producent i CRA-forstand. Det betyder, at I skal kunne fremvise teknisk dokumentation, sikre “security by design”, og have en proces for sårbarheder og opdateringer.
Importøren og distributøren
Importører og distributører får også konkrete pligter, bl.a. at sikre, at producenten har gjort sit hjemmearbejde, og at der følger korrekt information og dokumentation med. I praksis betyder det, at “vi køber det bare hjem” ikke længere er en holdbar model for smart home-produkter.
For integratorer (fx virksomheder der sammensætter belysning, adgangskontrol og kameraer i én løsning) opstår en gråzone: Hvis I ændrer produktet væsentligt, pakker software sammen på en ny måde eller leverer en ny kombination, kan I i praksis komme til at stå med producentlignende forpligtelser. Det er et område, hvor mange undervurderer risikoen, især når integrationen inkluderer egen app, egen cloud eller egne firmware-tilpasninger.
Designfasen: sådan kortlægger I produktrisici, før koden er skrevet færdig
De dyreste CRA-fejl opstår, når sikkerhed først bliver et tema i sluttest eller ved certificering/markedsføring. I connected home er det særlig kritisk, fordi produkter ofte har lange udviklingscyklusser, flere leverandørled og en forventning om at “det skal bare virke” for slutkunden.
Trusselsmodellering for smart home: et konkret eksempel
Tag et intelligent låsesystem: det har typisk en låseenhed, en bridge/gateway, en mobilapp og en cloud-tjeneste. En praktisk trusselsmodel vil kortlægge angrebsflader som BLE/Zigbee/Wi-Fi, pairing-processen, firmwareopdateringer, API’er, samt adgangsstyring i appen (fx familie-/gæsteadgang). Her er det ikke nok at sige “vi bruger kryptering”. I skal dokumentere, hvilke protokoller, nøglehåndtering, og hvordan I forhindrer replay-angreb, credential stuffing og misbrug af recovery flows.
Minimumsdiscipliner, der bør være standard
- Secure by design: sikkerhedskrav som en del af produktkrav (ikke en eftertanke).
- SBOM (Software Bill of Materials) for at kunne spore tredjepartskomponenter og CVE’er.
- Secure boot og signering af firmware, så uautoriseret kode ikke kan installeres.
- Hærdede standardindstillinger: ingen default-adgangskoder, ingen åbne debug-interfaces i produktion.
- Dataminimering: indsamling af kun nødvendige data, især for kamera/lyd.
- Plan for opdateringer: hvordan opdateres enheder sikkert i felten uden at “bricke” dem?
Et godt pejlemærke er at behandle et smart home-produkt som en lille computer i kundens hjem. Hvis en angriber kan overtage kameraet eller låsen, er konsekvensen fysisk og privatlivsmæssig, ikke bare digital.
Teknisk dokumentation ved markedsføring: det I skal kunne bevise, ikke bare gøre
CRA handler i høj grad om dokumenterbarhed. Mange teams har faktisk en del sikkerhed på plads, men kan ikke fremvise det i en sammenhængende struktur. Når I markedsfører et produkt i EU, skal I kunne vise, at kravene er opfyldt, og at I kan vedligeholde sikkerheden over tid.
I praksis bør jeres dokumentationspakke kunne besvare spørgsmål som: Hvilke sikkerhedskrav er implementeret? Hvilke risici er identificeret, og hvordan er de mitigated? Hvilke komponenter indgår? Hvordan testes der? Hvordan håndteres sårbarheder? Hvordan opdateres der?
Hvad koster det at få dokumentationen på plads?
Det afhænger af modenhed og produktkompleksitet, men et realistisk billede for mange SMV’er er, at den største omkostning ikke er værktøjer — det er tid fra udvikling, QA og produktledelse til at etablere en sporbar proces. Hvis I allerede arbejder med CI/CD, ticketing og release notes, kan I ofte “løfte” meget af arbejdet ved at standardisere artefakter: krav, risikovurderinger, testbeviser, SBOM og release- og patchhistorik. Hvis I derimod har firmware og app-udvikling uden formaliseret change management, bliver det typisk et større løft.
Sårbarhedshåndtering og opdateringer: sådan gør I CRA til en løbende proces
Den største mentale omstilling for mange smart home-aktører er, at compliance ikke er et projekt med en slutdato. CRA forudsætter, at I kan håndtere sårbarheder, udsende patches og kommunikere med markedet, så længe produktet er i drift og forventes brugt.
Det er her, mange falder igennem: Produktet bliver lanceret, teamet går videre til næste model, og der er ingen fast ejer af sikkerhedsopdateringer. I CRA-kontekst er det en risikabel situation, fordi sårbarheder i IoT ofte opdages måneder eller år efter lancering, især i tredjepartsbiblioteker.
At arbejde systematisk med CRA compliance betyder i praksis, at I etablerer en vedvarende “security operations”-rygrad omkring produktet: klare SLA’er for triage, patching og kommunikation, en sårbarhedsproces der kan tåle pres, og en release-mekanisme der kan opdatere enheder sikkert i felten.
En pragmatisk sårbarhedsproces, der virker i virkeligheden
- Etabler en offentlig vulnerability disclosure-kanal (fx security.txt og en dedikeret mail).
- Definér triage: hvem vurderer alvor, exploitability og påvirkede versioner?
- Hold styr på SBOM og komponentversioner, så I hurtigt kan afgøre påvirkning.
- Planlæg patch: udvikling, test, signering og staged rollout.
- Kommunikér: advisories til kunder/partnere, release notes og evt. mitigations.
- Følg op: verificér udrulning, monitorér fejlrate og regressions.
Løbende softwareopdateringer: OTA er ikke bare en feature
Over-the-air opdateringer er ofte det, der afgør, om et smart home-produkt kan holdes sikkert. Men OTA skal designes sikkert: signering, rollback-beskyttelse, beskyttelse mod man-in-the-middle, og en robust strategi for “partial connectivity” (enheder der kun er online sporadisk). En klassisk faldgrube er at bygge en OTA-kanal, der virker i laboratoriet, men fejler i virkelige hjem med ustabilt Wi‑Fi — hvorefter teamet slår sikkerhedstjek fra “for at få det til at virke”. Det skaber et permanent sikkerhedshul.
Ansvar og governance: hvem ejer hvad fra udvikling til direktionsniveau?
CRA presser organisationen til at tage stilling til ansvar. Ikke kun “hvem skriver koden”, men hvem der ejer risikobeslutninger, dokumentation, og driftsforpligtelser. I praksis bør I undgå, at compliance lander som en løs opgave hos QA eller en enkelt sikkerhedsperson uden mandat.
Et enkelt ansvarskort (RACI) for smart home-produkter
- Produktledelse: ejer sikkerhedskrav i roadmap, accepterer residual risiko og prioriterer patching vs. features.
- Udvikling (firmware/app/cloud): implementerer kontroller, leverer SBOM, tests og release-artefakter.
- QA/Release: sikrer sporbarhed, testbeviser, signering, og at releases følger proces.
- Security/Compliance: driver trusselsmodellering, sårbarhedsprocesser, audits og træning.
- Support/Customer Success: håndterer kundekommunikation ved advisories og opdateringer.
- Direktion: sikrer ressourcer, governance og beslutningskraft ved alvorlige hændelser.
En gennemgående faldgrube er, at ingen “ejer” produkter efter lancering. CRA gør post-launch-ansvaret eksplicit: hvis I ikke har et vedligeholdelses-setup, er det ikke bare dårlig praksis — det kan blive et compliance-problem.
Typiske fejl i bolig- og indretningssegmentet — og hvordan I undgår dem
Connected home-produkter bliver ofte indkøbt og pakket som en del af en større løsning: “smart living”-pakker, premium-køkkener med app-styring, eller sikkerhedsløsninger til boligprojekter. Det skaber nogle tilbagevendende fejlmønstre.
Faldgruber, der går igen
- Blind tillid til leverandøren: “De siger, det er sikkert” uden SBOM, testbeviser eller patchplan.
- Uklare opdateringsforpligtelser: hvem betaler for cloud-drift og patches om 3–5 år?
- Default credentials eller svage onboarding-flows i appen.
- Manglende logning og telemetry, så I ikke kan opdage misbrug eller fejl i udrulninger.
- Fragmenteret dokumentation: viden ligger i Slack-tråde og enkeltpersoners hoveder.
- Ingen plan for end-of-life: hvad sker der, når produktet udfases, men stadig er i hjemmene?
Den mest effektive modgift er at gøre sikkerhed og dokumentation til en del af produktets “Definition of Done”. Hvis et release ikke kan spores, reproduceres og forklares, er det et rødt flag.
Hvad skal I gøre nu: en handlingsplan for de næste 60–90 dage
Hvis I står med en portefølje af smart home-produkter, er det sjældent realistisk at “fikse alt” på én gang. I får mest effekt ved at etablere de processer, der skaber kontinuerlig kontrol, og derefter arbejde risikobaseret på de mest kritiske produkter og angrebsflader.
- Lav en produktliste: hvilke produkter med digitale elementer sælger I i EU, inkl. tilhørende apps og cloud?
- Udpeg ejerskab: hvem er produktansvarlig for sikkerhed efter lancering?
- Start SBOM: generér og vedligehold for firmware, app og backend.
- Gennemfør trusselsmodellering på 1–2 “flagskibsprodukter” og genbrug skabelonen.
- Etabler vulnerability disclosure og intern triage-proces med klare tidsmål.
- Gennemgå OTA-opdateringskæden: signering, rollback, staged rollout og fail-safes.
- Saml dokumentation: krav, risici, tests, release notes og patchhistorik i ét system.
Hvis I samtidig arbejder med nye produktlanceringer i 2026, bør I sikre, at sikkerhedskrav og dokumentationskrav ligger i kravspecifikationen fra dag ét. Det er markant billigere at justere arkitektur og processer tidligt end at “compliance-retrofitte” et produkt, der allerede er i produktion.
