CRA Klass I Efterlevnadsguide: routrar, modem, switchar

Publicerad 28 maj 2026 Uppdaterad 30 maj 2026

Sammanfattning

En hem-Wi-Fi-router, modem-router, internetmodem, mesh-routernod eller switch bör normalt planeras som en viktig produkt i Klass I. Förbehållet är kärnfunktionen: en router som främst marknadsförs som en brandvägg, IDS/IPS, VPN-gateway eller nätverkshanteringsapparat kan behöva en annan kategoriskanalys.

Den första bevisåtgärden är ett klassificerings- och avgränsningsmemo för den exakta CPE:n eller nätverksenheten. Det bör identifiera hårdvaran, firmware, WAN-gränssnittet, den trådlösa stacken, LAN-administratörsgränssnittet, mobilappen, ISP- eller leverantörsmolnet, fjärrhanteringskanalen, uppdateringsmekanismen, komponentinventariet, supportperioden och varje privat märkning eller ISP-ändring av firmware.

Produktvariant Trolig CRA-klass Varför
Konsument-Wi-Fi-router Viktig Klass I Internetanslutning och routing är kärnfunktionen
ISP-modem-router eller CPE Viktig Klass I Produkten ansluter kunder till internet
Fristående kabel-, DSL- eller fibermodem / ONT Viktig Klass I när avsedd för internetanslutning Internetmodemfunktionen är produktens kärnfunktion
Mesh-Wi-Fi-kit Viktig Klass I Mesh-noderna bildar routerprodukten eller produktfamiljen
4G/5G mobil hotspot Viktig Klass I Mobil WAN är fortfarande internetanslutning
Hanterad switch Viktig Klass I Växling plus ett hanteringsplan passar nätverksproduktfunktionen och utökar bevisavgränsningen
Ohanterad eller icke-konfigurerbar switch Variantspecifik Kontrollera om den är en produkt med digitala element och om det finns något hanteringsplan, väg för firmwareuppdatering, moln-/appfunktion eller annan uppkopplad funktion innan du behandlar den som hanterad nätverksutrustning
VPN-router Variantspecifik, vanligen Viktig Klass I VPN kan vara den mer specifika funktionen om den marknadsförs så
Router marknadsförd som brandvägg, UTM eller IPS Variantspecifik, möjligen Viktig Klass II Brandvägg eller förebyggande kan bli kärnfunktionen
Kommersiell routerfirmware såld fristående Variantspecifik Programvaruprodukten kan själv vara routerprodukten
ISP-märkt CPE med OEM-hårdvara Viktig Klass I, rollkänslig Privat märkning eller firmwareändringar kan flytta tillverkarskyldigheter

Klassificeringsgrund

Klassificeringsvägsbeslut för en router, modem eller switch. En topfråga om den marknadsförda kärnfunktionen förgrenar sig tre vägar. Gren A, markerad: en router, internetmodem eller hanterad switch är Viktig Klass I punkt 12 eftersom routing och internetanslutning är kärnfunktionen. Gren B: en låda som främst marknadsförs som en brandvägg eller ett intrångsdetekterings- och förebyggandesystem väcker frågan om Klass II punkt 2. Gren C: en ohanterad eller icke-konfigurerbar switch, eller en kommersiell firmware-avbild med öppen källkod, behöver en variantspecifik kontroll. En fotnot anger att paketfiltrering, föräldrakontroller eller en VPN-klient inte i sig flyttar en router till Klass II.
Den första vägfrågan är den marknadsförda kärnfunktionen: en router eller ett modem stannar i Klass I punkt 12; en brandväggsförst-låda väcker frågan om Klass II punkt 2.

CRA behandlar routrar, internetmodem och switchar som viktiga Klass I-produkter, vilket inte är samma sak som Klass II-brandväggsstatus. Extra säkerhetsfunktioner flyttar inte en router till Klass II så länge routing och internetanslutning förblir den marknadsförda kärnfunktionen.

Produkten är inte Kritisk enbart för att den sitter vid nätverkskanten. Den kritiska listan är smalare och inkluderar inte konsumentroutrar eller ISP-CPE som helhet.

Vad räknas som routerprodukten?

En router-, modem- eller switchprodukt kan omfatta mer än plastlådan:

  • bootloader, operativsystem, kärna, trådlösa drivrutiner, WAN-stack och LAN-tjänster;
  • modem, ONT, Ethernet-switch-kisel, hanteringsbeteende för VLAN och PoE-kontroll där den finns;
  • webbadministratörsgränssnitt, mobilappsparning och lokal installationsportal;
  • TR-069, USP/TR-369 eller annan fjärrhanteringskanal;
  • leverantörs- eller ISP-moln som används för fjärråtkomst, föräldrakontroller, telemetri, mesh-samordning eller uppdateringsorkestrering;
  • firmwareuppdateringstjänst, signeringsnycklar, återställningsbild och supportprocess.

Bevisfilen bör också registrera vad som ligger utanför produkten: kundens ISP-konto, smarta hem-enheter från tredje part, kundförfattade nätverksregler, användarens modem när det säljs separat, och nedströms operatörssystem som inte levereras av tillverkaren.

Vilken överensstämmelseväg bör tillverkaren planera för?

Viktig Klass I innebär inte automatiskt att varje router behöver en tredjepartsbedömning, men intern kontroll bör inte tas för given. Om tillverkaren kan använda den allmänna interna kontrollvägen och har tillämpat de relevanta harmoniserade standarderna, gemensamma specifikationerna eller en lämplig europeisk cybersäkerhetscertifieringsordning på en tillförsäkringsnivå på minst betydande för de tillämpliga väsentliga kraven, kan den vara tillgänglig. Om dessa referenser inte finns, bara delvis tillämpas, inte tillämpas, eller inte täcker alla relevanta krav, planera för EU-typkontroll plus intern produktionskontroll eller fullständig kvalitetssäkring. Den allmänna vägens mekanik och vad EU-försäkran om överensstämmelse måste innehålla finns i guiderna bedömning av överensstämmelse och försäkran om överensstämmelse; denna sida behandlar endast det routerspecifika valet.

Om samma hårdvaruvariant också marknadsförs som en brandvägg, VPN-gateway, nätverkshanteringsapparat eller hanterad säkerhetsplattform, skapa ett separat klassificeringsmemo för den SKU:n.

Hur kopplar RED-cybersäkerhetsdeadlinen till CRA?

De flesta routrar och internetanslutna modem innehåller en radio (Wi-Fi, ett mobilmodem eller liknande), och den radioutrustade delmängden har redan passerat en cybersäkerhetsgrind innan CRA anländer. Från den 1 augusti 2025 tillämpas radioutrustningsdirektivets cybersäkerhetskrav (RED Artikel 3.3 punkterna d, e och f, satta av Delegerad förordning (EU) 2022/30) på internetansluten radioutrustning såsom Wi-Fi-routrar, mesh-noder, modem-routrar och mobila gateways. En rent kabelbunden enhet, såsom en endast Ethernet-router eller ett rent DSL-, kabel- eller fibermodem utan radio, ligger utanför RED:s cybersäkerhetsomfattning, men var och en av dem är fortfarande en produkt med digitala element enligt CRA. CRA-rapporteringsskyldigheter börjar den 11 september 2026 och CRA blir fullt tillämplig den 11 december 2027, då kommissionens upphävande av RED-cybersäkerhetsdelegerade förordningen genom Delegerad förordning (EU) 2026/339 träder i kraft så att de två regimerna inte överlappar.

Tidslinje som kopplar radioutrustningens cybersäkerhetsdeadline till CRA. Från den 1 augusti 2025 möter internetansluten radioutrustning RED:s cybersäkerhetskrav (punkterna d, e och f). RED-cybersäkerhetsdelegerade förordningen upphävs sedan av Delegerad förordning (EU) 2026/339, och CRA blir fullt tillämplig den 11 december 2027, med rapporteringsskyldigheter som börjar den 11 september 2026. En parallell standardbana visar EN 18031-serien för RED-fasen, ETSI EN 304 627 som utkast till CRA-routerstandard, och EN 40000 horisontella utkast.
Routertillverkare passerar en cybersäkerhetsgrind för radioutrustning från augusti 2025; samma skyldigheter flyttar under CRA från december 2027.

För en routertillverkare är den praktiska läsningen:

  • Mellan den 1 augusti 2025 och den 10 december 2027 möter tillämplig radioutrustning RED:s cybersäkerhetskrav; den harmoniserade vägen löper genom EN 18031-serien, med ETSI EN 303 645 som konsumentbaslinjen den bygger på.
  • Från den 11 december 2027 sitter samma cybersäkerhetsskyldigheter under CRA, med dess bredare livscykelskyldigheter: säker-som-standard-konfiguration, sårbarhetshanteringsprocess, supportperioduttalande och rapporteringsskyldigheter som redan börjar den 11 september 2026.
  • En router som redan släppts på marknaden före den 11 december 2027 omfattas av CRA endast om den väsentligt modifieras efter det datumet. Det enda undantaget är rapporteringsskyldigheten, som gäller för varje produkt inom tillämpningsområdet, inklusive enheter som redan sålts.
  • Den routerspecifika CRA-harmoniserade standard som förbereds är ETSI EN 304 627 (routrar, modem och switchar), som kopplas till Klass I punkt 12 och de väsentliga cybersäkerhetskraven. Den är fortfarande ett utkast, så planera överensstämmelsevägen på de standarder som faktiskt är angivna vid tillfället, och återanvänd de kontroller som byggts för RED (säkra standardinställningar, signerade uppdateringar, åtkomstkontroll) som grund för CRA-filen i stället för att starta ett separat projekt.

Vilken bevisning bör finnas på plats?

Bevisområde Vad som ska fångas för en router eller modem-router Varför det är viktigt
Avsett syfte Hemrouter, ISP-CPE, modem, ONT, mesh-system, mobil hotspot, switch, VPN-router, hanterad switch Klassen följer den faktiska produktvarianten och påståendena
WAN-attackyta DHCP, PPPoE, IPv6, DNS-proxy, NAT, brandväggsstandard, fjärradminställning WAN-sidan tar emot opålitlig trafik innan användaren har konfigurerat något
LAN-administration Webbgränssnitt, lokalt API, installationsportal, lösenordspolicy, kontoåterställning, åtkomstkontroller De flesta konfigurations- och ägarmisstag sker här
Trådlöst WPA2/WPA3-standard, WPS-beslut, gästisolering, SSID/lösenord-onboarding, firmware för Wi-Fi-chip Trådlösa standardinställningar blir hushållets säkerhetsstandard
Fjärrhantering TR-069, USP/TR-369, leverantörsmoln, ISP-moln, fjärråtkomst via mobilapp Detta är ofta skillnaden mellan en låda och en flotthanterad produkt
Uppdateringsväg Signerad firmware, skydd mot nedgradering, ISP-tryckta releaser, återställningspartition, uppdateringsmeddelande Routeruppdateringar måste täcka supportperioden och överleva OEM/ISP-grenar
Leverantörsbevis SoC SDK, Wi-Fi/basbandsleverantör, bootloader, kärna, TLS-stack, DNS/DHCP-tjänster Routertillverkare ärver en stor tredjepartskomponentyta
Rollbevis OEM, ISP, importör, distributör och ansvar vid privat märkning Märkta CPE:er och firmwaregrenar kan ändra vem som äger CRA-filen

Vilka detaljer i routerarkitekturen får inte missas?

Routerbevis måste följa den kantenhet som faktiskt levereras. En Wi-Fi-router för detaljhandel, ISP-modem-router, PON ONT, kabelmodem, mobil hotspot, mesh-nod och hanterad switch har olika WAN-exponering, fjärrhantering och firmwaregrenrisker.

En routergateways internkomponenter ritade som fyra horisontella planband. Dataplanet innehåller WAN-porten, LAN-switchen, Wi-Fi-radion och hårdvaruavlastningen. Kontrollplanet, som körs på SoC-CPU:n, innehåller routing och NAT, brandvägg, DHCP och DNS, och Wi-Fi-autentisering. Hanteringsplanet innehåller webbadministratörskonsolen, SSH, SNMP, TR-069- och USP-agenten, och OTA-uppdateringsklienten. Plattformslagret innehåller säker uppstart, A- och B-firmwarebankerna, och flash plus DRAM. Varje plan är en distinkt grupp komponenter som hör hemma i tillverkarens produktfil.
Routern delas upp i fyra plan: datavidarebefordran, kontrollprogramvaran på CPU:n, hanteringsåtkomst och plattformen som startar och lagrar allt. Alla fyra hör hemma i produktfilen.
En nav-och-eker-karta över vem som talar med routern. Routern sitter i mitten inuti en streckad produktfilgräns. På hushållssidan: en lokal administratörsenhet och hushållets LAN- och IoT-enheter. På operatörs- och internetsidan: det opålitliga internet, ISP- eller operatörs-autokonfigurationsservern, firmwareuppdateringsservern och leverantörsmolnet. Sju märkta flöden korsar gränsen: WAN-uplänk, LAN-trafik, Wi-Fi-association, lokal administration, fjärrhantering, signerad firmwareuppdatering och leverantörstelemetri.
Varje flöde här korsar produktfilgränsen: WAN-uplänken, LAN och Wi-Fi till hushållet, lokal administration, operatörens fjärrhantering, signerade uppdateringar och molntelemetri. Filen måste redovisa dem alla.
Arkitekturkontrollpunkt Bevisfråga för router, modem eller switch
Uppstartkedja och återställning Identifiera boot-ROM, bootloader, säker uppstartstatus, A/B- eller enkelbanksbild, återställningsutlösare, anti-rollback-räknare och beteende vid fabriksåterställning. Behåll nedgraderings- och återställningsmissbrukstest.
WAN och provisionering Separat Ethernet-WAN, PPPoE, DHCP, IPv6, DOCSIS/PON/mobilprovisionering och operatörsprofiler. Visa vilka tjänster som parsar oautentiserad WAN-indata innan administratörsgränssnittet finns.
Wi-Fi och basbandslager Spåra Wi-Fi-firmware-blobbar, konfiguration av regulatorisk domän, hostapd/wpa_supplicant-grenar, WPS-beslut och mesh-onboarding. Leverantörsfirmware hör hemma i rådbevakningen.
Fjärrhantering För TR-069/CWMP, USP/TR-369, leverantörsmoln eller ISP-moln, registrera kontrollantidentitet, certifikatförtroende, anslutningsförfrågansbeteende, kommandoomfattning och granskningsbarhet.
Switch- och mesh-kontroll Gränssnitt för hanterad switch, SNMP/API, VLAN, portspegling, PoE, EasyMesh eller proprietära mesh-kontrollanter behöver sina egna kontroller av hanteringsplanets exponering. För ohanterade eller icke-konfigurerbara switchar, verifiera först om en digital hanterings- eller uppdateringsyta finns.
ISP- och privatmärkningsgrenar Behåll en grenmatris som visar OEM-bygge, ISP-gren, operatörsprofil, OTA-godkännande, supportperiodsägare och väg för användarmeddelande.
Tillverkning och retur Registrera per-enhets-hemligheter, tryckta inloggningsuppgifter, debug-skalpolicy, UART/JTAG-status, RMA-radering och molnavbindning.

WAN-sidan är där enheten först parsar oautentiserad indata, och den sidan ändras med åtkomstteknologin. En Ethernet-WAN-router för detaljhandel, en kabelmodem-router, en fiber-ONT och en mobil hotspot delar inte samma provisioneringskanal eller samma uppströms-peer.

WAN-åtkomstteknologivarianter för en kantenhet till internet. Ett DSL-modem ansluter till en DSLAM vid växeln; ett kabelmodem ansluter till en CMTS över en länk krypterad och certifikat-autentiserad med BPI+ eller SEC; en fiber-ONT ansluter genom en passiv splitter till en OLT; en Ethernet-WAN-port ansluter till en uppströmsswitch; och en mobilmodul ansluter till ett mobilnät. Varje variant noterar vad som ändras vid WAN-förtroendegränsen: åtkomst-peern, provisioneringskanalen och den oautentiserade indata som först når enheten.
WAN-gränsen skiljer sig efter åtkomstteknologi: DSL, kabel, fiber, Ethernet eller mobil ändrar var och en åtkomst-peern och den första oautentiserade indata.

Hur ser en verklig router-riskbedömning ut?

Använd detta som ett exempel på det djup som förväntas i en hotmodell för produktfilen. Tillverkaren behöver fortfarande köra bedömningen mot den verkliga routern, modem-chipsetet, trådlösa stacken, fjärrhanteringskanalen, leverantörens SDK:er, uppdateringsägarskap, försäljningspåståenden och supportperiodlöfte.

Exempel på produktprofil

Exempelprodukt: ExampleCo HomeRouter R1, en Wi-Fi 7-hemrouter som säljs i EU genom detaljhandel och ISP white-label-kanaler. Den har Ethernet-WAN, fyra LAN-portar, gäst-Wi-Fi, ett lokalt webbadministratörsgränssnitt, mobilapp-onboarding, valfri ISP-fjärrhantering, signerad OTA-firmware, automatiska uppdateringskontroller, DNS/DHCP-tjänster, föräldrakontrollprofiler och en återställningsbild.

Produktavgränsningen inkluderar routerhårdvaran, bootloader, kärna, Wi-Fi-drivrutiner, WAN-tjänster, LAN-tjänster, brandväggsstandard, lokalt webbgränssnitt, mobilapp-parning, leverantörsmoln för fjärråtkomst, valfri ISP-fjärrhanteringsagent, OTA-tjänst, återställningsbild, supportwebbplats, mottagning för samordnat avslöjande och rådprocess. Den utesluter kundens modem när det säljs separat, ISP-abonnemanget, smarta hem-enheter från tredje part, användarens identitetsleverantör, och nedströms ISP OSS/BSS-system om inte samma ekonomiska aktör levererar dem som del av produkten.

Provisioneringslivscykel för exempelroutern från fabrik till retur. Steg ett, fabrik: per-enhets-identitet, unika inloggningsuppgifter, certifikat och ett standard-SSID. Steg två, WAN-anslutning: Ethernet, PPPoE, DOCSIS, PON eller mobil avgör den första oautentiserade indata. Steg tre, provisionera: operatören eller leverantören binder en ACS- eller USP-profil och kommandoomfattning. Steg fyra, onboard: tvingad lösenordsändring, gästisolering och WPS-beslutet. Steg fem, firmware: en signerad baslinje som avvisar nedgraderingar. Steg sex, återställning, vidareförsäljning eller RMA: molnavbindning, tokenåterkallelse och rensning av mesh-medlemskap. Ett nedre band listar de negativa testen som måste klaras vid varje övergång.
Varje livscykelsteg namnger vad som ändras och kontrollen som bevisar att fel aktör inte kan ta över routern.
HomeRouter R1 bevisavgränsning Routerfilen behöver koppla hårdvara, firmware, trådlöst, molnhantering, ISP-varianter och drift under supportperioden.
Mer operatörsberoende
Kund- och ISP-miljö Driftsantaganden
ISP-konto Separat modem Smarta hem-enheter Hushållets slutpunkter ISP OSS-verktyg
Bevis

Dokumentera antaganden om förväntad hemanvändning, ISP-provisionering, administratörsägarskap och driftslägen som inte stöds.

Där routertillverkarens produkt börjar
Routerhårdvara Släppt på EU-marknaden
WAN LAN-switch Wi-Fi-radior SoC Återställningsknapp Återställningsplats
Bevis

Produktfil | SKU-avgränsningsmemo | hotfil | EU-försäkran om överensstämmelse | CE-märkning | supportperioduttalande

Firmware och tjänster Attackyta att bedöma
Bootloader Kärna DNS/DHCP Webbadmin TR-069 / USP OTA-agent
Bevis

Komponentinventarium | tjänsteinventering | trådlös standardtest | säker uppdateringstest | granskning av fjärrhantering

Leverantörslager Tillsyn av routerkomponenter
SoC SDK Wi-Fi-firmware Ethernet-drivrutin TLS-bibliotek DNS-tjänst Mobil-SDK
Bevis

Leverantörsråd, SDK-versionsregister, ägarskap för firmwaregren, komponent-CVE-triage och bevis för patch-spridning.

Under supportperioden
Levande CPE-flotta Uppdateringar och rollöverlämning
OEM-firmwarekorrigeringar ISP-grensammanslagningar Säkerhetsråd Användarmeddelanden Rapportering av utnyttjande
Bevis

Behåll grenmatrisen, uppdateringsreleaseregistret, ISP-godkännandespåret, rådregistret och rapporteringsbeslutsregistret för aktivt utnyttjade sårbarheter eller allvarliga säkerhetsincidenter.

ISP-märkt CPE behöver särskild bevisning eftersom produkten kan dela design, märkning, firmwaregodkännande, fjärrhantering och användarsupport mellan olika ekonomiska aktörer.
Exponeringsfönster vid första uppstart för exempelroutern. En tidslinje löper från strömpå, där fabriksstandard är aktiva, till onboardad, där standarderna är ersatta och fönstret är stängt. Mellan dem står ett exponeringsfönster öppet och fyra saker kan redan nå routern innan användaren ändrar något: WAN-indata från DSL, DOCSIS, PON eller mobil som parsas före inloggning; det levererade standard-SSID:t och lösenordet; en operatörs TR-069 eller USP-server som kan binda en profil; och leverantörsmoln, mobilparning och OTA-slutpunkter. Ett band listar vad som stänger fönstret vid onboarding: tvingad lösenordsändring, signerad firmwarebaslinje, omfångsbegränsad fjärrhantering och gästnätverksisolering.
Releasegrind: firmwareteknik äger baslinjen för första uppstart, produktsäkerhet äger exponeringstestet, och support äger bevisen för återställning och RMA. Artefakt: provisioneringsregister, exponeringsskanning efter installation, nedgraderingsavslagstest och resultat för överföring eller avbindning.
Fråga besvarad: innan hushållet ändrar någon inställning, vilken WAN-indata, operatörsprofil och standardtjänst kan redan nå routern?
Kommandogräns för fjärrhanteringTR-069/CWMP, USP/TR-369, leverantörsmoln och ISP-moln bör omfattas som flottkontrollvägar.
Kommandoområde
Typisk åtgärd
Riskfråga
Bevis att behålla
Konfiguration
DNS, Wi-Fi, brandvägg, portvidarebefordran eller bryggläge.
Kan kontrollanten ändra mer än den bedömda profilen tillåter?
Kommandoomfattningsmatris och granskningsstickprov.
Diagnostik
Loggar, paketräknare, linjestatistik eller supportpaket.
Läcker exporten SSID, tokens, kundidentifierare eller topologi?
Redaktionstest och datainventering.
Firmware
Operatörsgodkänd uppdatering, återställningsbild eller grenbyte.
Kan ett gammalt eller fel regionalt bygge tryckas?
Signerat manifest, grenkarta och avvisning av rollback.
Ägarskap
Molnparning, ISP-migrering, enhetsretur eller vidareförsäljning.
Kan tidigare ägare, ISP eller app-token fortfarande kontrollera lådan?
Återställnings-, avbindnings- och migreringstest.
Bevisgrind: fjärrhantering är en flottkontrollväg, inte bara en operatörsfunktion. Releasefilen bör binda varje kontrollantidentitet till kommandoomfattning och firmwaregren. Artefakt: TR-069/USP-profilgranskning, kontrollantcertifikatinventering och kommando-granskningsstickprov.
Fråga besvarad: vilket fjärrhanteringskommando kan ändra DNS, brandvägg, firmware eller ägarstatus, och vem godkände den omfattningen?
Grenmatris för OEM-, ISP- och privatmärkt firmwareSamma hårdvara kan levereras med olika supportägare, molnslutpunkter och patchtider.
OEM-basReferensfirmware och komponentinventarium

Källgren, SDK-version, Wi-Fi-firmware, kärna och signeringsnyckel är utgångsbaslinjen.

ISP-grenOperatörsprofil och releasegrind

ACS/USP-slutpunkt, märkning, standardkonfiguration, godkännandeflöde och ägare av användarmeddelande dokumenteras.

Detaljhandels-SKULeverantörsmoln och appbindning

Mobilapp, molnparning, mesh-tjänst och supportperioduttalande förblir under leverantörens releaseprocess.

PatchsammanslagningSpridning av säkerhetskorrigering

Spåra om OEM-, ISP- och privatmärkningsgrenar fick samma säkerhetskorrigering eller ett dokumenterat undantag.

Patch-grind: supportperiodlöftet följer den firmwaregren som användarna faktiskt får. Bevis: grenmatris, komponentinventariediff per gren, ISP-godkännandespår, ägare av privatmärkningsrelease och dokumenterat undantag där en gren inte kan ta samma korrigering.
Fråga besvarad: när OEM:en korrigerar en routersårbarhet, hur bevisar varje ISP-, detaljhandels- och privatmärkningsgren att korrigeringen nådde sina användare?

Tillgångsinventering

Tillgång Varför den är viktig Var den finns
WAN-till-LAN-trafikkontroll Kontrollerar hushållets exponering mot internet NAT, brandväggsstandard, kärnnätverk
Routeradministratörskonto och sessioner Ger kontroll över DNS, Wi-Fi, portvidarebefordran, uppdateringar och återställning Webbgränssnitt, mobilapp, lokalt token-lager, molnkonto
Wi-Fi-inloggningsuppgifter och gästisolering Svaga standarder exponerar hemnätverket och anslutna enheter Wi-Fi-konfiguration, onboarding-flöde, regler för gästnätverk
Inloggningsuppgift för fjärrhantering En flottkontrolluppgift kan påverka många routrar TR-069/USP-agent, certifikatlager, ISP ACS/moln
Förtroendeankare för firmwaresignering Skyddar router-uppdateringskanalen Bootloader, säker lagring, OTA-tjänst
DNS/DHCP-konfiguration Kan omdirigera användare eller bryta anslutning Lokala tjänster, administratörsgränssnitt, ISP-provisionering
Switchhanteringsstatus VLAN, portisolering, PoE och hanteringsåtkomst kan exponera nedströmsnätverk Hanterat-switch-gränssnitt, CLI, SNMP/API, switch-ASIC-konfiguration
Modem/ONT-provisioneringsstatus Registrering, brygg-/routerläge och hanteringsuppgifter påverkar internetkanten Modem-firmware, operatörsprofil, fjärrhanteringsagent
Support- och diagnostikloggar Kan avslöja SSID:er, serienummer, IP:er, kundkontolänkar och kraschdata Enhetsloggar, mobilapp, supportportal
Status för firmwaregren ISP/OEM-grendrift kan lämna sårbarheter oåtgärdade OEM Git/releasesystem, ISP-gren, OTA-arkiv
Status för säker uppstart och anti-rollback Skyddar återställningsvägen och förhindrar att kända sårbara bilder återvänder Bootloader, eFuse/RPMB/TPM-status, produktionsregister
Wi-Fi/basbandsfirmware Radio-firmware kan påverka autentisering, tillgänglighet och nätverksexponering Wi-Fi-chip, firmware-blob, leverantörs-SDK, produktionsbild

Förtroendegränser

Miljö Förväntad exponering Riskkonsekvens
WAN-gränssnitt Kontinuerligt exponerat för opålitlig nätverkstrafik Parserfel och exponerade tjänster kan kompromettera enheten
LAN och installationsnätverk Delat med hushållets slutpunkter och IoT-enheter Lokala angripare kan rikta in sig på administratör, upptäckt och svaga standardinställningar
Trådlöst gränssnitt Nåbart från fysisk närhet WPS, svag onboarding eller fel i gästisolering exponerar LAN
Switchens hanteringsplan Nåbart från administratörs-VLAN, LAN eller operatörsverktyg beroende på konfiguration Svaga standarder kan exponera VLAN, PoE-kontroll eller spegelportar
Fjärrhanteringsväg Når enheten från leverantörs- eller ISP-infrastruktur Läckage av inloggningsuppgifter eller ACS-kompromiss kan skala över många routrar
OTA- och återställningsväg Tar emot privilegierade firmware-bilder Svag signering eller rollback undergräver alla säkerhetskorrigeringar
ISP/privatmärkningsgren Kan ändra firmware, molnslutpunkter och supportperiod Skyldigheter kan flyttas när ett varumärke styr release- och supportbeslut

Hotscenarier

ID Hotscenario Tillgång i riskzonen Ingångspunkt
R1 WAN-administratörsslutpunkt är aktiverad som standard eller via ISP-profil Administratörskonto, routerkonfiguration WAN
R2 Förstaanvändningslösenord är delat, förutsägbart eller tryckt på ett sätt som återanvänds över batcher Administratörskonto, Wi-Fi-uppgifter Onboarding
R3 DHCP-, IPv6-, DNS- eller PPPoE-parserfel kan utlösas före autentisering Routerintegritet, tillgänglighet WAN-tjänster
R4 TR-069- eller USP-inloggningsuppgift läcker och tillåter fjärrkonfigurationsändringar Inloggningsuppgift för fjärrhantering, DNS, firmwarekanal ISP/leverantörshantering
R5 OTA-återställning accepterar osignerad eller äldre firmware Firmwareintegritet OTA / återställning
R6 Gäst-Wi-Fi kan routa till LAN-enheter eller administratörsgränssnitt Hushållets slutpunkter, routeradministratör Trådlöst / LAN
R7 WPS- eller QR-onboarding kan missbrukas efter initial installation Wi-Fi-uppgift Trådlös onboarding
R8 Debug-skal, telnet, SSH eller UART förblir tillgängliga i produktion Routerintegritet, hemligheter Firmware / fysisk
R9 ISP-märkt firmwaregren missar en OEM-säkerhetskorrigering Status för firmwaregren Releaseprocess
R10 Mobilappens fjärråtkomsttoken förblir giltig efter routeröverföring eller fabriksåterställning Administratörskonto, ägarskap Moln / app
R11 DNS- eller föräldrakontrollsmoln-fel skapar osäkert reservbeteende DNS-integritet, tillgänglighet Molnberoende
R12 Leverantörssårbarhet i SoC SDK, Wi-Fi-firmware eller medlevererad nätverksdaemon triageras inte under supporten Routerintegritet, tillgänglighet Leverantörskomponent
R13 Hanterat-switch-gränssnitt eller SNMP/API exponeras på användar-LAN med svaga standarduppgifter Switchhanteringsstatus, VLAN-integritet LAN / hanteringsplan
R14 Modem- eller ONT-provisioneringsprofil aktiverar fjärradmin eller bryggläge utanför den bedömda releasen Modem/ONT-provisioneringsstatus, WAN-exponering Operatörsprovisionering
R15 Återställningsläge, reset-hold-uppstart eller TFTP-återställning accepterar en oautentiserad eller nedgraderad bild Firmwareintegritet, status för säker uppstart Bootloader / återställning
R16 Wi-Fi-firmware, mesh-onboarding eller WPS-beteende skiljer sig mellan hårdvarurevisioner utan releasebevis Wi-Fi-uppgifter, gästisolering Trådlös / leverantörs-SDK
R17 USP/TR-369- eller TR-069-kommandoomfattning tillåter mer än operatörsprofilen avsåg Inloggningsuppgift för fjärrhantering, DNS, OTA ISP/leverantörshantering
R18 Appbindning eller molnägartoken överlever fabriksåterställning eller ISP-retur Administratörskonto, ägarskap Återställning / molnkonto

Inledande riskregister

ID Sannolikhet Påverkan Inledande beslut Motivering
R1 Låg Hög Behandla före release Fjärradminsexponering ger direkt kontroll och är lätt att skanna
R2 Medel Hög Behandla före release Hushållsanvändare behåller ofta standardinställningar om inte onboarding tvingar fram ändring
R3 Medel Hög Behandla före release WAN-parsare är exponerade före autentisering
R4 Medel Allvarlig Behandla före release Fjärrhanteringsfel kan skala över en ISP-flotta
R5 Låg Allvarlig Behandla före release Firmware-rollback kan hålla kända sårbara byggen vid liv
R6 Medel Medel Behandla före release Gästisolering är en grundläggande användarförväntan
R7 Medel Medel Behandla före release Närhetsattacker är realistiska i lägenheter och delade utrymmen
R8 Medel Hög Behandla före release Debug-åtkomst är en återkommande produktionsväg ut
R9 Medel Hög Behandla före release Grendrift är förutsebar när OEM- och ISP-releaser separeras
R10 Medel Hög Behandla före release Routervidareförsäljning och ISP-returflöden är förutsebara
R11 Låg Medel Behandla före release Molnberoende kontroller behöver säkert reservbeteende
R12 Medel Hög Behandla före release Routerkomponentstaplar tar emot sårbarheter under hela supporten
R13 Medel Hög Behandla före release Hanterat-switch-konfiguration kan påverka många nedströmsenheter
R14 Låg Hög Behandla före release Provisioneringsdrift kan exponera internetkanten på flottnivå
R15 Medel Allvarlig Behandla före release Återställning är en privilegierad väg som angripare och serviceteam kan nå
R16 Medel Hög Behandla före release Radio- och mesh-beteende ändras ofta med leverantörens SDK och hårdvarurevisioner
R17 Medel Allvarlig Behandla före release Omfattningsfel i fjärrhantering kan påverka flottor
R18 Medel Hög Behandla före release Routerreturer, vidareförsäljning och ISP-byten är normala livscykelhändelser

Koppling mellan kontroller och bevis

Hot Designkontroll Bevisning som tillverkaren bör behålla
R1, R8 WAN-admin avstängd som standard, tjänsteinventering för produktion, brandväggsregler för hantering, ingen telnet eller fabriksskal Exponeringsskanningar, checklista för produktionsbild, tjänstelistdiff
R2, R7 Unik installationshemlighet eller tvingad uppgiftsskapelse, kort parningsfönster, WPS avstängd eller motiverad, hastighetsbegränsningar Onboarding-test, bevis för uppgiftsgenerering, granskning av trådlös installation
R3 Parserhärdning, fuzzing, tjänsteprivilegieseparation, default-drop-WAN-hållning Fuzzing-rapporter, design för tjänsteisolering, krasch-triage
R4 Ömsesidig autentisering, certifikatrotation, minsta privilegium vid provisionering, granskning av ACS/USP-profil Säkerhetsgranskning av fjärrhantering, register för certifikatlivscykel
R5 Säker uppstart, signerad firmware, monoton versionsräknare, signaturkontroller för återställningsbild OTA-testrapport, nedgraderingsavslag, återställningstest
R6 Isolering av gästnätverk, administratörsgränssnitt nås inte från gäst, regressionstester över mesh-noder Test för nätverksisolering, mesh-roaming-test
R9 OEM/ISP-grenmatris, policy för patchsammanslagning, releasegodkännande, samordning av supportens slut Grenmatris, register för patch-spridning, ISP-godkännandespår
R10 Arbetsflöde för ägaröverföring, molnavbindning vid återställning, tokenåterkallelse, radering av returnerad enhet Återställningstest, ägaröverföringstest, RMA-checklista
R11 Lokalt DNS-reservbeteende, säkert reservläge för föräldrakontroll, tydligt användarmeddelande Test av reservläge, bevis för användarmeddelande
R12 Övervakning av komponentinventarium, mottagande av leverantörsråd, ägare av firmwarekomponent, spårbarhet av versionsnoteringar Komponentinventariediff, rådlogg, register för komponentbeslut
R13 Bindning av hanteringsplan, unik administratörsinstallation, SNMP/API avstängd eller härdad som standard, VLAN-isoleringstest Exponeringsskanning, standardkonfigurationstest, granskning av switchhantering
R14 Bedömd provisioneringsprofil, begränsningar för fjärradmin, operatörsändringskontroll, rollback- och granskningsspår Register för provisioneringsprofil, granskning av flottkonfiguration, operatörsgodkännandespår
R15 Autentiserad återställning, signerad återställningsbild, anti-rollback-status, fysisk återställningsvarning där relevant Test av återställningsmissbruk, register för uppstartkedja, nedgraderingsavslag
R16 Hårdvarurevisionsmatris, Wi-Fi-firmwareinventering, WPS/mesh-regressionstester, granskning av regulatorisk domän Revisionsmatris, register för radio-firmware, trådlösa installationstest
R17 Profil för fjärrhantering med minsta privilegium, kontrollantcertifikatinventering, kommando-granskning och godkännande TR-069/USP-profilgranskning, register för certifikatlivscykel, granskningsstickprov
R18 Arbetsflöde för ägaröverföring, molnavbindning vid återställning, ISP-returradering, tokenåterkallelse Återställningstest, checklista för returnerad enhet, bevis för molnavbindning

Restrisk efter kontroller

Kvarstående område Varför den finns kvar Driftbevis
ISP-grendrift OEM- och ISP-releasegodkännande kan röra sig i olika takt Grenmatris, eskaleringsväg, granskning av releasedelta
Kompromiss av hushållets slutpunkt Skadlig kod på en LAN-klient kan fortfarande attackera lokal administration eller DNS-inställningar Lokala autentiseringskontroller, tokenåterkallelse, administratörsvarningar
Nya WAN-sårbarheter WAN-vänd kod fortsätter att ta emot fientlig trafik under supportperioden Övervakning av utnyttjande, fuzzing-kadens, akut uppdateringsprocess
Eftersläpning av leverantörsfirmware Wi-Fi- och SoC-leverantörer kan släppa korrigeringar i sin egen takt Register för leverantörs-SLA, dämpningsnoteringar, kundrådprocess

Hur bör support, uppdateringar och rapportering fungera?

För HomeRouter R1-exemplet bör den praktiska CRA-filen inkludera supportperiodens driftsmodell, inte bara bevisen från före marknadsplacering.

Driftområde Bevis att förbereda
Supportperiod En supportperiodsmotivering för detaljhandels-SKU:n och den ISP-märkta SKU:n, med månad/år-slutdatum synligt vid köp och i routergränssnittet där tekniskt möjligt. Om inte förväntad användning är kortare, planera för minst fem år.
Tillgång till säkerhetsuppdateringar Säkerhetsfirmware-korrigeringar och säkerhetsuppdateringspaket förblir hämtbara i minst 10 år efter utfärdande, eller under återstoden av supportperioden om längre. Återställningsbilder, hashar, versionsnoteringar och rollback-beslut bör bevaras som bevis, men inte varje icke-säkerhetspaket bör beskrivas som ett juridiskt 10-årigt tillgänglighetslöfte.
OEM- och ISP-grenmatris Vilken firmwaregren som är bedömd, vem som signerar den, vem som godkänner release, vem som äger akuta korrigeringar och hur uppströms säkerhetskorrigeringar når privatmärkta byggen.
Enskild sårbarhetskontakt En direkt kontakt för sårbarhetsrapportering hos den registrerade tillverkaren, inte bara abonnentsupport eller en automatisk chatbot. Om en ISP är tillverkare för en märkt SKU äger ISP:n en mottagningsväg för produktsäkerhetsrapporter.
Tillsyn av komponenter Övervakning av komponentinventarium för kärna, trådlös firmware, DNS/DHCP-tjänster, TLS-stack, mobil-SDK:er och fjärrhanteringsagent, med triage av leverantörsråd, uppströmsmeddelande och korrigeringsdelning där så är lämpligt.
Arbetsflöde för aktivt utnyttjande Rapportering genom den gemensamma rapporteringsplattformen till den CSIRT som utsetts till samordnare och till ENISA: tidig varning inom 24 timmar, uppföljningsmeddelande inom 72 timmar, slutgiltig sårbarhetsrapport inom 14 dagar efter att en korrigerande eller dämpande åtgärd finns tillgänglig, och meddelande till påverkade användare eller dämpningsinstruktioner där så är lämpligt.
Arbetsflöde för allvarlig produktsäkerhetsincident Rapportering genom samma plattform och adressater: tidig varning inom 24 timmar, uppföljningsmeddelande inom 72 timmar, slutgiltig incidentrapport inom en månad efter incidentmeddelandet, och kund/ISP-samordning inklusive användarmeddelande där så är lämpligt.
Innehållsförteckning för produktfil Produktidentitet, gränsdiagram, WAN/LAN/trådlösa tillgångar, hotmodell, riskregister, kontroller, testbevis, komponentinventarium, uppdateringsprocess, sårbarhetsprocess, supportperiodsmotivering, instruktioner, försäkran och register över överensstämmelseväg.

Vilka valideringsgrindar körs före release?

En router-release bör inte passera på en oklar "säkerhetsgranskad" notering. Lista de specifika beslut som kan hålla leveransen, och ge var och en det fel den vaktar mot, kontrollen som stänger den och artefakten som bevisar att kontrollen faktiskt körs.

Router-releasegrindar och avslutningsregister Sex beslut som en routertillverkare bör kunna stänga före godkännande, var och en med en namngiven bevisartefakt.
  1. G1FörstaanvändningsuppgifterBlockera release
    • Fel

      Ett delat eller förutsägbart administratörs- eller Wi-Fi-lösenord, eller en tryckt hemlighet som återanvänds över en batch.

    • Kontroll

      Unik per-enhets-hemlighet eller tvingad uppgiftsskapelse; WPS av eller motiverad.

    • Bevis

      Onboarding-test och bevis för uppgiftsgenerering.

  2. G2WAN-exponering efter provisioneringBlockera release
    • Fel

      Fjärradmin, eller en onödig eller obedömd tjänst som parsar oautentiserad WAN-indata, är nåbar innan användaren har konfigurerat något.

    • Kontroll

      WAN-admin av som standard, default-drop-hållning, parserhärdning och en minimal tjänstelista.

    • Bevis

      WAN-exponeringsskanning efter provisionering.

  3. G3Trådlös och gästisoleringBlockera release
    • Fel

      Gästnätverket kan routa till LAN-enheter eller nå administratörsgränssnittet.

    • Kontroll

      Gästisolering som standard; administratörsgränssnitt inte nåbart från gäst; regression över mesh-noder.

    • Bevis

      Test av nätverksisolering och mesh-roaming.

  4. G4Uppdaterings- och återställningsvägBlockera release
    • Fel

      OTA eller återställning accepterar en osignerad eller äldre firmware-bild.

    • Kontroll

      Säker uppstart, signerade bilder, en monoton versionsräknare och nedgraderingsavslag.

    • Bevis

      Resultat av misslyckad nedgradering och återställningsmissbrukstest.

  5. G5Omfattning för fjärrhanteringBlockera om inte dokumenterad
    • Fel

      TR-069- eller USP-kommandoomfattningen låter kontrollanten ändra mer än den bedömda operatörsprofilen.

    • Kontroll

      Profil med minsta privilegium, kontrollantcertifikatinventering, kommando-granskning.

    • Bevis

      Profilgranskning och kommando-granskningsstickprov.

  6. G6LeverantörsstackLeverera med övervakning
    • Fel

      En sårbarhet landar i SoC SDK, Wi-Fi-firmware eller en medlevererad nätverksdaemon under supportfönstret.

    • Kontroll

      Komponentinventering med namngiven ägare, rådbevakning och beredskap för backport.

    • Bevis

      Triagebeslut för påverkad komponent.

Blockera releaseBlockera om inte dokumenteradLeverera med övervakning
Varje router-releasegrind parar ett leveransstoppande fel med registret som stänger den.

Vem äger routerutvecklingen från koncept till support?

Ägarskapet av en router-release byter händer när den går från en produktdefinition till en flotta som körs i kundernas hem och på ISP-nätverk. Rälsen nedan ger varje steg en enda ansvarig ledare, det register som ledaren håller aktuellt och grinden som måste stängas före nästa steg startar.

Ägarräls för en router-release över sex steg från koncept till support: koncept, design, firmware, release, drift och support. Varje steg namnger ledarägaren, det underhållna registret och granskningsgrinden. Frysmarkörer sitter mellan stegen: frys avgränsning, frys design, frys kandidat, frys beslut, fortsätt drift. En streckad återkopplingsloop går tillbaka från support till koncept och signalerar att sårbarhetsrapporter, ISP- och leverantörsråd och utfall av utnyttjade fel öppnar nästa avgränsningsmemo, hotlista och komponentinventering.
Ägarrälsen tilldelar registerägaren, stängningsgrinden och granskningssignalen vid varje byggsteg.

Varje övergång är en fryspunkt: avgränsningen är fastlåst före arkitekturen startar, designintentionen före kod, bygget före verifiering och releasen före leverans, varefter firmware hålls körande genom supportfönstret. En sårbarhetsrapport, ett ISP- eller leverantörsråd, eller ett fältfel öppnar nästa avgränsningsmemo, hotlista och komponentinventering snarare än den som redan levererats.

Vilka bevisregister hör hemma i filen?

Filen bör låta en granskare följa routerbeslutet från produktidentitet till säkerhetskontroller. Varje rad pekar på ett underhållet register, inte en mapp med osammanhängande skärmbilder.

Bevisområde Vad som ska fångas för en router, modem-router eller switch
Produktidentitet Modell, hårdvarurevisioner, SoC- och Wi-Fi-chipset, WAN-typ, firmwaregren, mobilappsversion, switch/mesh-alternativ
Avsett syfte Hemrouter, ISP-CPE, internetmodem, ONT, mesh-kit, mobil hotspot, hanterad switch eller VPN-router, med detaljhandels- och ISP-märkta varianter namngivna
Designdossier för cyberresiliens WAN-exponering, LAN och trådlösa standarder, fjärrhanteringsbehörighet, OTA- och återställningsväg, hotlista och behandlingsplan
Komponentinventarium Bootloader, kärna, Wi-Fi-firmware, WAN-PHY/modemstack, DNS/DHCP-tjänst, TLS-stack, fjärrhanteringsagent, mobil-SDK:er, med namngivna ägare och rådbevakning
Säkra standardinställningar Ingen delad standarduppgift, WAN-admin av som standard, signerade uppdateringar, nedgraderingsavslag, gästisolering, låsta debug-portar, tjänsteinventering efter provisionering
Uppdateringsmekanism Signerad firmware, återställningsbild, anti-rollback-status, ISP/OEM-grenkarta, användarens uppdateringsmeddelande
Sårbarhetshantering Redovisningspolicy, enskild kontaktpunkt, triagearbetsflöde, rådbevakning för komponenter, ISP/privatmärkt rådroutning
Användarinstruktioner Säker onboarding, lösenords- och gästinstallation, uppdateringsinställningar, redovisning av supportens slut, avveckling och återställning
Spårbarhet och kontakt Typ-/parti-/serieinformation, tillverkar- eller ISP-kontakt, supportperiodens slutdatum och en enskild sårbarhetsrapporteringskontakt som inte bara är en automatisk bot

Vad ingår i en router-SBOM?

CRA kräver ett maskinläsbart komponentinventarium som identifierar produktens komponenter och täcker minst beroenden på toppnivå, utan att namnge ett fast format ännu. Routertillverkare väljer normalt CycloneDX eller SPDX. De korsprodukt-detaljerade mekanikerna för komponentinventariet finns i den dedikerade SBOM-guiden; detta avsnitt täcker det routerspecifika trädet.

En router-release levererar flera digitala element med separata uppdateringscykler, inte en binär. Två mönster uppfyller CRA-minimum: en komponentinventering på produktnivå med elementseparerade sektioner (bootloader, kärna, Wi-Fi-firmware, WAN-PHY-stack, nätverksdaemoner, TLS, fjärrhanteringsagent och webbgränssnitt var och en versionsfastlåst), eller en inventering per levererat element som uppdateras vid varje release. Båda är godtagbara så länge den är maskinläsbar och beroenden på toppnivå täcks.

Ett vänster-till-höger rotat träd över komponentinventariet för en router-release. Roten är router-releasen. Åtta grenar når de digitala elementen på toppnivå som levereras i en router: bootloader och säker uppstartkedja, kärna och operativsystem, Wi-Fi-firmware, WAN-PHY och modemstack, nätverksdaemoner, TLS-bibliotek, fjärrhanteringsagent och webbadministratörsgränssnitt. Varje gren listar typiska komponenter som exempelblad, och en höger-märkning namnger identifierarschemat (PURL, CPE, leverantörs-ID, signatur eller bygghash). En fotnot upprepar CRA-minimum: beroenden på toppnivå i ett vanligt använt, maskinläsbart format som CycloneDX eller SPDX.
Komponentinventariet bör täcka varje digitalt element på toppnivå, dess vanliga innehåll och dess bevisning för versionslåsning.

Vad kontrollerar releasegodkännandet?

Godkännande före EU-releasen bör kunna stänga fyra registermappar, visade som Q1 till Q4 nedan. Det fullständiga filindexet finns i bevisningskartan ovan; de fyra frågorna här är bara de som blockerar releasen när en mapp är tom.

Mapp Releasefråga Routerspecifik bevisningspekare
Q1 Klassificeringsmotiveringsmemo Varför är denna produkt klassificerad som den är? Kärnfunktion (routing och internetanslutning), avsedd användning, försäljningspåståenden, detaljhandels- vs ISP-variant och vald överensstämmelseväg
Q2 Inventering av levererade element Vad är produkten exakt? Routerhårdvara, firmware, WAN/LAN/trådlösa tjänster, webbgränssnitt, fjärrhanteringsagent, OTA-tjänst, molnslutpunkter och de uteslutna kund/ISP-systemen
Q3 Testpaket för säkra standardinställningar Vad är säkrat som standard och hur uppdateras det säkert? Ingen delad standarduppgift, WAN-admin av som standard, signerade uppdateringar, nedgraderingsavslag, gästisolering, WPS-beslut, låsta debug-portar, tjänsteinventering efter provisionering
Q4 Sårbarhetshanteringsprocess Hur kommer sårbarheter och allvarliga incidenter att hanteras efter leverans? Offentlig kontakt, redovisningspolicy, triagearbetsflöde, rådbevakning för komponenter, ISP/privatmärkt rådroutning, beredskap för 24-timmars och 72-timmars meddelanden
Scen för releasegodkännande. Fyra registermappar ligger på granskningsskrivbordet, märkta Q1 till Q4: Q1 klassificeringsmotiveringsmemo, Q2 inventering av levererade element, Q3 testpaket för säkra standardinställningar och Q4 sårbarhetshanteringsprocess. Pilar från varje mapp konvergerar mot ett releasegodkännandesigill markerat med en bock. En anteckning listar förgodkända kontroller: filer fastlåsta till firmwaregren och leverantörsbaslinje, en namngiven ägare med beredskap för 24-timmars och 72-timmars meddelanden, och ett testpaket för säkra standardinställningar som täcker per-enhets-uppgifter och WAN-adminställningen. En fotnot upprepar grinden: om ett register saknas levereras inte releasen.
Bevis: fastlås vart och ett av de fyra registren till den exakta firmware-versionen de godkänner, så samma release kan öppnas igen senare utan att svaret behöver härledas på nytt.
Före godkännande bör tillverkaren peka på fyra register: klassificeringsmotivering, inventering av levererade element, säkra standardtester och beredskap för sårbarhetshantering.

Releasegodkännandemappar Q1 till Q4

  1. Q1 Klassificeringsmotiveringsmemo. Varför Klass I punkt 12? Kärnfunktion, avsedd användning, försäljningspåståenden, detaljhandels- vs ISP-variant och vald överensstämmelseväg.
  2. Q2 Inventering av levererade element. Routerhårdvara, firmware, WAN/LAN/trådlösa tjänster, webbgränssnitt, fjärrhanteringsagent, OTA-tjänst, molnslutpunkter och uteslutna kund/ISP-system.
  3. Q3 Testpaket för säkra standardinställningar. Ingen delad standarduppgift, WAN-admin av som standard, signerade uppdateringar, nedgraderingsavslag, gästisolering, WPS-beslut, låsta debug-portar.
  4. Q4 Sårbarhetshanteringsprocess. Offentlig kontakt, redovisningspolicy, triagearbetsflöde, rådbevakning för komponenter och rapporteringsberedskap för varningar, meddelanden och slutrapporter.

Godkännandegrind: om ett register saknas är releasen inte godkänd.

Hur lämnas routern över till importör, distributör, ISP och operatör?

Överlämning mellan ekonomiska aktörer för en router-release. Tillverkarens eller OEM:ens releasepaket färdas längs en flödesräls genom importörens förmarknadsacceptans, distributörens synliga tillsyn, ISP eller privatmärkt varumärke som kan bli tillverkaren, och operatören eller abonnenten. En rad med stoppvillkor namnger fallen som pausar leverans eller listning: paket-, spårbarhets-, supportdatum- eller sårbarhetskontaktavvikelse, eller en firmwaregren eller fjärrhanteringsprofil som skiljer sig från det bedömda bygget. Sidokontroll A förklarar att mandatet för auktoriserad representant är valfritt och att en tillverkare utanför EU utan ett sådant använder kaskaden importör, distributör och högsta användarbas. Sidokontroll B förklarar att en importör eller distributör under eget varumärke, eller en väsentlig modifierare såsom en märkt firmwaregren eller ett nytt hanteringsmoln, blir tillverkare för det erbjudandet.
Överlämningskartan visar vem som äger varje förförsäljningskontroll och vad som stoppar routern vid varje roll.

Överlämning mellan ekonomiska aktörer: roller och sidokontroller

  1. 01 Tillverkare / OEM. Äger releasepaketet: försäkran, CE, filindex, supportfönster och sårbarhetskontakt.
  2. 02 Importör. Verifierar paketet, CE, filindex, supportdatum och sårbarhetskontakt, och bekräftar att det mottagna bygget är det bedömda bygget: trådlösa landsinställningar, ISP-profiler, certifikat för fjärrhantering, appparning och OTA-slutpunkter. Pausa leverans om något av detta är tveksamt.
  3. 03 Distributör. Kontrollerar synlig CE, medlevererade dokument, support- och uppdateringsuttalanden, och lägger inte till påståenden såsom "säkerhetsgateway", "företagsbrandvägg" eller "hanterad VPN-apparat" som ligger utanför den bedömda avgränsningen. Pausa listning om den överstatar support, avviker från försäkran eller fortsätter sälja efter ett känt problem.
  4. 04 ISP eller privatmärkt varumärke. Märkning, molnhantering, uppdateringsägarskap och fjärrhanteringsdrift kan utlösa tillverkarskyldigheter på egen hand. Att placera routern under eget namn, eller att väsentligt modifiera den (märkt firmware, ett nytt moln, en ny uppdateringskanal), gör den till tillverkare för det erbjudandet, så leverantörsfilen är inte en ersättning för dess egen rollanalys.
  5. 05 Operatör eller abonnent. Tar emot råd och uppdateringar och rapporterar problem tillbaka. Inte tillverkare.

Sidokontroll A. Mandatet för auktoriserad representant är valfritt, men där det finns måste det vara skriftligt och täcka att hålla försäkran och dokumentationen tillgänglig och att samarbeta med myndigheter. En tillverkare utanför EU utan ett sådant använder kaskaden: importör, distributör, sedan största användarbas. Utan en EU-baserad aktör i rapporteringskedjan faller rapporteringsslutpunkten på den medlemsstat där flest användare finns.

Sidokontroll B. En importör eller distributör under eget varumärke, eller varje väsentlig modifierare, blir tillverkare för det påverkade erbjudandet.

Vanliga frågor

Är en router Klass II för att den har en brandvägg?

Inte som standard. En normal router är vanligen Viktig Klass I. Den blir en Klass II-fråga när brandväggsfunktion, intrångsdetektering eller intrångsförebyggande är produktens kärnfunktion.

Omfattas en ISP-levererad router?

Ja, om den placeras på EU-marknaden som en produkt med digitala element. Den centrala praktiska frågan är vem som är tillverkare för den märkta firmware, supportperioden, uppdateringskanalen och sårbarhetsprocessen.

Är en router Kritisk?

Nej. Konsumentroutrar, ISP-modem-routrar och switchar är inte Kritiska enbart för att de är viktiga för nätverksåtkomst.

Ändrar kommersiell routerfirmware med öppen källkod svaret?

Det kan göra det. En kommersiellt levererad firmware-bild eller apparatdistribution kan själv vara en produkt med digitala element. Tillverkaren bör dokumentera vad som placeras på marknaden och vem som äger uppdateringar och sårbarhetshantering.

Om programvaran genuint kvalificerar som fri och öppen källkod och faller i en viktig kategori har CRA en specifik överensstämmelseoption där den nödvändiga tekniska dokumentationen är offentlig vid marknadsplacering. Tillämpa inte den vägen på en privat ISP-firmwaregren eller en kommersiell apparat enbart för att den inkluderar paket med öppen källkod.

Innebär att möta RED-cybersäkerhetsdeadlinen att en router redan är CRA-kompatibel?

Nej. Från den 1 augusti 2025 möter internetansluten radioutrustning radioutrustningsdirektivets cybersäkerhetskrav, och de kontrollerna (säkra standardinställningar, uppdateringsintegritet, åtkomstskydd) är rätt grund. Men CRA lägger till en bredare livscykel: en dokumenterad sårbarhetshanteringsprocess, ett publicerat slutdatum för supportperioden, säker som standard över hela produkten och rapporteringsskyldigheter. RED-cybersäkerhetsdelegerade förordningen upphävs från den 11 december 2027, då CRA tar över.

Återkontrollutlösare: behandla RED-filen som utgångspunkt och gap-bedöm den mot CRA:s väsentliga krav före den 11 december 2027.

Vilken harmoniserad standard gäller för en router under CRA?

För radioutrustningsfasen är den harmoniserade uppsättningen EN 18031-serien, byggd på ETSI EN 303 645 som konsumentbaslinjen. Den routerspecifika CRA-standarden under förberedelse är ETSI EN 304 627 (routrar, modem och switchar), som kopplas till Klass I punkt 12. Den är fortfarande ett utkast, så bekräfta de angivna standarderna och eventuella harmoniseringsbegränsningar vid tidpunkten för bedömningen.

Överensstämmelseregister: ett kort memo som namnger de standarder man stödjer sig på, versionen, eventuell begränsning som inte passar produkten och den resulterande överensstämmelsevägen.

Behandlas en hanterad switch som en router, och är en ohanterad switch inom omfattningen?

En hanterad switch har ett hanteringsplan (webbgränssnitt, CLI, SNMP/API, VLAN) och en väg för firmwareuppdatering, så den behandlas normalt som Viktig Klass I-nätverksutrustning med egen bevisning för hanteringsplanet. En rent ohanterad, icke-konfigurerbar switch utan hanteringsyta, utan firmwareuppdatering och utan uppkopplad funktion behöver en variantspecifik kontroll av om den är en produkt med digitala element över huvud taget.

Avgränsningsregister: en enradsnotering per switch-SKU som anger om en hanterings- eller uppdateringsyta finns.

Är mesh-Wi-Fi-kit en produkt eller flera?

Mesh-noderna som bildar ett system är normalt routerprodukten eller produktfamiljen. Bedöm kitet som levererat: kontrollantnoden, satellitnoderna, onboarding-flödet och mesh-kontrollprotokollet. Internodförtroende och onboarding-handslaget är del av den trådlösa attackytan.

Avgränsningsregister: namnge noderna i kitet, mesh-kontrollprotokollet och onboarding-metoden i avgränsningsmemot.

Omfattas ett fristående modem eller ONT om det bara bryggar?

Ett modem, kabelmodem eller fiber-ONT avsett för internetanslutningen är normalt Viktig Klass I, även i bryggläge, eftersom internetmodemfunktionen är produktens kärnfunktion och enheten fortfarande har firmware, en provisioneringskanal och ofta en fjärrhanteringsagent. Brygg- vs routerläge ändrar exponeringen, inte den grundläggande klassificeringen.

Avgränsningsregister: registrera provisioneringskanalen, fjärrhanteringsagenten och om brygg- eller routerläge är den bedömda standarden.

Är en 4G- eller 5G-mobil hotspot inom omfattningen?

Ja. Mobil WAN är fortfarande internetanslutning, så en mobil hotspot eller 4G/5G-router är normalt Viktig Klass I. Den mobila provisioneringsvägen och SIM/eSIM-hantering är del av WAN-attackytan.

Avgränsningsregister: namnge mobilmodulen, provisioneringsvägen och hanteringskanalen.

Hur länge måste en router stödjas och uppdateras?

Supportperioden är minst fem år om inte den förväntade användningstiden är kortare; många routrar och ISP-CPE körs mycket längre, så filen bör ange ett fönster som tillverkaren faktiskt kan leverera och visa slutdatumet före köp. Säkerhetsuppdateringar bör förbli hämtbara i minst tio år efter utfärdande, eller under återstoden av supportperioden om längre. De allmänna reglerna finns i guiderna supportperiod och redovisning av supportens slut.

Supportregister: en supportperiodsmotivering för detaljhandels-SKU:n och den ISP-märkta SKU:n, med slutdatumet synligt vid köp och i routergränssnittet där det är möjligt.

Vad räknas som en säker uppdatering för en router?

En signerad firmware-bild, verifierad genom en säker uppstartkedja, med en monoton versionsräknare så att ett äldre sårbart bygge inte kan installeras om, och en återställningsväg som också avvisar osignerade eller nedgraderade bilder. ISP-tryckta och OEM-uppdateringar måste båda följa denna väg.

Testartefakt: en signerad uppdateringsverifieringslogg, ett misslyckat nedgraderingstest och ett återställningsmissbrukstest för det exakta firmware-bygget.

Ändrar TR-069- eller USP-fjärrhantering produktavgränsningen?

Om tillverkaren eller ISP:n levererar fjärrhanteringskanalen är den innanför avgränsningen och är en flottkontrollväg, inte bara en operatörsfunktion. Operatörens autokonfigurationsserver, anslutningsförfrågansmekanismen, kommandoomfattningen och certifikatförtroendet hör alla hemma i bedömningen.

Bevis: en kontrollantcertifikatinventering och en kommandoomfattningsmatris bunden till den bedömda operatörsprofilen.

Vem är tillverkare för ISP-märkt CPE?

Den som placerar produkten på marknaden under eget namn eller varumärke, eller väsentligt modifierar den bedömda produkten. En ISP som ommärker OEM-hårdvara, grenar firmware, kör hanteringsmolnet eller äger uppdateringskanalen kan ta på sig tillverkarskyldigheter för den märkta SKU:n, inklusive sårbarhetsrapporteringskontakten.

Rollregister: en skriftlig uppdelning av vem som äger försäkran, firmwaregrenen, uppdateringskanalen, supportperioden och rapporteringskontakten.

Vilket är det första bevisobjektet en routertillverkare bör skapa?

Ett kort klassificerings- och avgränsningsmemo för den exakta SKU:n: router, modem-router, mesh-kit, switch, hotspot eller VPN-router. Namnge WAN-typen, den trådlösa stacken, LAN-adminytan, fjärrhanteringskanalen, molntjänsterna, uppdateringsägarskapet, supportperioden och de uteslutna systemen.

Klassificeringsregister: ett en-sidigt memo som hotmodellen, valet av överensstämmelseväg, importörspaketet och supportperioduttalandet alla kan hänvisa till.

Vad händer om en sårbarhet hittas i routerfirmware efter release?

Vidta korrigerande åtgärder omedelbart och var redo för rapporteringssekvensen: en tidig varning på 24 timmar för en aktivt utnyttjad sårbarhet, ett meddelande på 72 timmar, en slutrapport när en korrigerande eller dämpande åtgärd finns tillgänglig, och användarmeddelande. För en router är den korrigerande åtgärden vanligen en signerad firmwareuppdatering som trycks över OEM-, ISP- och privatmärkningsgrenarna, med ett dokumenterat undantag där en gren inte kan ta samma korrigering. De allmänna rapporteringsmekanikerna finns i guiderna sårbarhetshantering och samordnat avslöjande av sårbarheter.

Register över korrigerande åtgärd: påverkade modeller och firmwaregrenar, den signerade uppdateringsartefakten, grenspridningsspåret, användarrådstexten och meddelandereferensen.

När bör routerns riskbedömning uppdateras?

Varje gång en levererad router ändras på ett sätt som flyttar en förtroendegräns: en ny WAN-typ, en ny fjärrhanteringsprofil, en Wi-Fi- eller SoC-SDK-ändring, ett nytt molnberoende, en ändring av mesh-onboarding, en ändring av debug-portens beteende eller en ny ISP-gren. En releasenotering räcker inte om ändringen öppnar en exponering eller behörighetsväg igen. Rapporteringsskyldigheter gäller från den 11 september 2026, så redovisningspolicyn och den enskilda kontakten bör fungera innan dess.

Återkontrollutlösare: varje ändring av WAN-exponering, trådlösa standardinställningar, omfattning för fjärrhantering, uppdateringsväg, leverantörskomponenter eller ISP-gren öppnar avgränsningsmemot och riskbedömningen.

Nästa steg

Börja med SKU-nivå-avgränsningsmemot: router, modem-router, mesh-kit, switch, VPN-router eller brandväggsvariant. Kartlägg sedan firmware, trådlös stack, fjärrhantering, molntjänster, leverantörskomponenter, uppdateringsägarskap och supportperiod in i produktfilen; den korsprodukt-strukturen av den filen finns i guiden för teknisk dokumentation.