För inte så länge sedan var säkerhet i IoT något som ofta hanterades sent i utvecklingsprocessen. Inte för att det saknades kompetens, utan för att andra faktorer styrde: funktionalitet, kostnad och tiden att ta produkten till marknaden. Säkerheten fick anpassa sig till det som redan var byggt, testa gjorde man sist i kedjan när allt var klart.
Den logiken håller inte längre.<
Det vi ser nu är inte bara en ökning av krav, utan en förskjutning i var de träffar. Regelverken NIS2, CRA, RED och Data Act – har en gemensam effekt: de flyttar säkerhetstänktet från slutet av utvecklingsprojektet in i konstruktionsfasen av IoT-produkten. Det är där avgörande avväganden behöver ske. Detta blir särskilt tydligt i hårdvarunära system, där val som görs tidigt i arkitekturen i praktiken är omöjliga att ändra i efterhand.
EU-reglerna som gör secure by design oundvikligt
Det är lätt att betrakta NIS2 som ett organisationskrav, CRA som ett produktregelverk och RED som något som rör radioutrustning. Men i praktiken konvergerar de i samma punkt: den fysiska IoT-produkten.
NIS2 driver krav bakåt genom leverantörskedjan, vilket innebär att även komponentval och designbeslut påverkas. RED, konkretiserat genom EN 18031, sätter en teknisk lägstanivå för vad som är en acceptabel säkerhetsnivå i uppkopplade IoT-produkter. CRA lägger till ett livscykelansvar där tillverkaren inte bara ansvarar för produkten vid leverans, utan under hela dess livstid. Samtidigt förändrar Data Act hur data exponeras och delas, vilket påverkar både arkitektur och gränssnitt.
Detta innebär att säkerhet inte längre kan hanteras som ett lager ovanpå allt annat, säkerhet måste byggas in i själva konstruktionen, från komponentnivå och uppåt, det vi kallar secure by design.
Secure by design – men vad betyder det i praktiken?
Ett intressant whitepaper från Rapid7 visar hur relativt enkla angrepp kan räcka långt när grundläggande säkerhetsprinciper saknas. Genom att manipulera kretskortet och utnyttja oskyddade debug-gränssnitt, bristfällig uppdateringsmekanik eller svag – i vissa fall obefintlig – autentisering mellan enhet och backend, går det att extrahera credentials direkt ur systemet.
Det som sticker ut är inte attackens komplexitet, utan frånvaron av motstånd. Det krävs inga avancerade metoder, bara att någon utnyttjar det som lämnats öppet i designen.
Och det är just här kopplingen till secure by design blir konkret. De nya regelverken försöker inte bara hantera risker – de adresserar de återkommande designbrister som gång på gång dyker upp i verkliga implementationer, och flyttar ansvaret till den punkt där de faktiskt kan elimineras: i konstruktionen av IoT-produkten.
Det kan handla om att firmwareuppdateringar saknar signering, att nycklar hanteras oskyddat i mjukvaran, eller att debug-gränssnitt lämnas öppna för att förenkla utveckling och produktion. Det här är naturligtvis inte okej, och det regleras i RED:s cybersäkerhetsdel, men det måste efterlevas. Möter inte produkten grundläggande krav skall den inte säljas inom EU. Det handlar inte bara om vad som är tekniskt lämpligt, som tidigare, utan det handlar om konkreta regelverk som skall efterlevas. Det är här secure by design går från princip till krav.
Låt oss bryta ned det
När man bryter ner begreppet handlar det i grunden om att kryptografiska nycklar ska genereras, lagras och användas i en säker exekveringsmiljö, inte exponeras i generell programvara. Firmware måste vara signerad och verifierad genom hela kedjan, från bootloader till applikation. Kommunikationen ska vara säkrad från första paketet, med autentisering och skydd mot replayattacker, och inte bara bestå av krypterad transport. Samtidigt måste fysiska gränssnitt som UART, JTAG eller andra debug-portar betraktas som en del av attackytan och hanteras därefter, inte lämnas som en kvarleva från utvecklingsfasen, dess måste alltså vara skyddad. Detta är beslut som i praktiken låser arkitekturen. När produkten väl är i fält är det för sent att rätta till dem utan omfattande omdesign av hårdvara eller mjukvara.
EN 18031 som konkretisering
I arbetet med RED:s cybersäkerhetskrav är EN 18031 regelverket som definierar vad som krävs inom områden som åtkomstkontroll, autentisering, säker uppdatering, skydd av data och nycklar samt säker kommunikation.
Det intressanta är inte att dessa områden är nya, utan att de nu är formaliserade och testbara. Det räcker inte längre att hävda att en lösning är säker – det måste gå att visa.
För många befintliga IoT-produkter innebär detta att den ursprungliga arkitekturen inte räcker till. För nya produkter innebär det att ribban ligger betydligt högre från start.
Säkerhet över hela livscykeln
Med Cyber Resilience Act förändras dessutom tidsperspektivet. En IoT-produkt kan inte längre betraktas som färdig vid leverans. Den ska kunna uppdateras på ett säkert sätt, hantera sårbarheter när de upptäcks och stödja incidentrapportering inom givna tidsramar.
Till detta kommer kraven kopplade till digitala produktpass, där spårbarhet och datatillgänglighet sträcker sig över hela livscykeln. Även avvecklingen blir en del av säkerhetsarbetet, där känslig information och kryptografiskt material måste hanteras och destrueras kontrollerat.
Detta innebär att säkerhet inte längre är en egenskap hos produkten, utan en kontinuerlig process som följer den från design till avveckling.
Där skillnaden uppstår
Det är lätt att se detta som ytterligare en komplexitet i IoT. Men det går också att se det som en tydlig struktur som tidigare saknats.
För de aktörer som arbetar hårdvarunära innebär detta en möjlighet att särskilja sig. Genom att ta kontroll över identitet, nyckelhantering och uppdateringsmekanismer redan i konstruktionen, minskar beroendet av sena anpassningar och externa åtgärder.
Secure by design handlar i det här läget inte bara om att uppfylla krav, utan om att bygga produkter som faktiskt går att sätta på marknaden utan friktion.
Och det är där IoT i praktiken avgörs framöver.