How a Home Router Is Made: Chipsets, Board Design, Firmware and Updates

A home router is a small Linux computer built around a networking system on chip (SoC), with one or more Wi-Fi radio chips, an Ethernet switch, a few megabytes to a gigabyte of flash, some RAM, radio front-end modules and antennas. Most brands start from a chipset maker's reference design and software development kit (SDK), so the board, the bootloader, the Linux kernel and the wireless drivers often look alike across brands. The board is assembled by surface mount lines, calibrated and RF tested unit by unit, certified by the FCC before it can be sold in the US, and then flashed with a firmware image whose update path, signing keys and support period decide how safe it stays.

This post goes one level deeper than our comparison of open source and stock router firmware and our history of Wi-Fi generations. It follows a router from silicon to the boxed product, then looks inside the firmware: the bootloader, the kernel, BusyBox, the wireless drivers, the web interface and the SDK that ties them together. It explains why router images carry so many old open source components, what a GPL source release can tell you, how signed images and secure boot are meant to work, and what the US Cyber Trust Mark, the UK PSTI regime and the EU Cyber Resilience Act now ask of router makers. It ends with commands you can run against your own router. Where a manufacturer keeps a number private, such as test yields or the cost of a calibration station, we say so instead of guessing.

Key takeaways

• A router is a computer. The SoC has CPU cores, a packet engine and often an integrated Wi-Fi radio; separate radio chips, a switch, flash, RAM, front-end modules and antennas sit around it on a multilayer board.
• Many brands ship near-identical boards because chipset makers sell a reference design and an SDK together. The SDK fixes the bootloader, kernel version and wireless drivers long before a brand writes its web interface.
• Each unit is calibrated for radio power on the production line, and the calibration data is written to its own flash partition. OpenWrt's documentation notes that if that partition is missing or corrupt, the Wi-Fi driver will not come up.
• In the US, a Wi-Fi router needs FCC certification through a Telecommunication Certification Body before it is marketed. 47 CFR 15.407(i) requires 5 GHz (U-NII) devices to resist unauthorized software changes that would push the radio outside its approved parameters.
• Router firmware is mostly open source: a bootloader such as U-Boot, a Linux kernel, BusyBox, a DHCP and DNS server, a Wi-Fi authenticator, a TLS library and a web UI. Old versions of each persist because the SDK pins them.
• GPL version 2 requires source code (or a written offer for it, valid for at least three years) for GPL binaries. A GPL source release is the most honest component list a router maker publishes.
• Secure boot is a chain: a key hash fused into the SoC verifies the first loader, the loader verifies the next stage, and U-Boot can refuse any kernel image that lacks a required signature. NIST IR 8425A asks for signed updates and protection against rollback to known vulnerable versions.
• The UK has banned universal default passwords and required a published security update period for connectable products since 29 April 2024. The EU CRA's reporting duties applied from 11 September 2026 and its main obligations apply from 11 December 2027. The FCC's Cyber Trust Mark page says the program does not include routers at first.

Silicon to boxed product in one table

The table is the map for the rest of the post. Manufacturers do not publish per-station yields or reject rates, so the table names the check at each stage rather than inventing percentages.

Two steps matter most for security. Step 2 fixes most of the software years before you buy the router. Step 8 is the cheap moment to set up a secure boot root of trust; if the fuse is never blown at the factory, the device usually cannot be made to boot only signed code later.

What is inside a home router?

Open any recent home router and you find a single board with a metal shield or two, a heat sink, a handful of large chips and a lot of small passives. Each chip has a job.

The SoC

The networking SoC is the brain. It contains one to four CPU cores (ARM or MIPS in most home designs), a memory controller, Ethernet MACs, USB and PCIe controllers, a crypto block and, in most current parts, a packet processing engine that forwards and translates traffic without waking the CPU for every packet. Many SoCs also include one Wi-Fi radio, usually the 2.4 GHz one, on the same die.

The boot ROM inside the SoC is the first code that runs at power on. It is written into the silicon and cannot be changed, which is why it is the anchor of any secure boot chain. Beside it sit OTP fuses that can hold a hash of the manufacturer's public key and settings such as "only boot signed images" or "disable JTAG".

Wi-Fi radio chips

The remaining radios, usually 5 GHz and on Wi-Fi 6E and Wi-Fi 7 routers also 6 GHz, are separate chips connected over PCIe. A tri-band router can have three radio chips plus the SoC. Each radio chip runs its own firmware blob, loaded by the Linux driver from the router's filesystem at boot. That firmware is closed source on most consumer parts, so it is a second software supply chain inside the box, one you cannot rebuild yourself.

Front-end modules and antennas

Between each radio and its antenna sits a front-end module: a power amplifier for transmit, a low noise amplifier for receive, a switch and filters. On a 4x4 radio there are four of these chains per band. The antennas may be external sticks on SMA connectors or printed and stamped metal elements inside the case. Antenna placement is one of the main things a brand changes from the reference design, because it depends on the enclosure.

The Ethernet switch

The LAN ports are driven by a switch, either a separate chip or a block inside the SoC. It forwards traffic between LAN ports in hardware and connects to the CPU through one or more internal links. Newer routers with 2.5 Gbit or 10 Gbit ports add separate physical layer chips (PHYs) for those ports.

Flash and RAM

Firmware lives in flash. OpenWrt's flash layout documentation describes the two kinds you will meet. Raw NOR flash in routers is generally small, 4 to 16 MiB, and free of bad blocks, and older routers typically use it. Raw NAND flash is generally 32 MiB to 1 GiB, cheaper per megabyte and faster for bulk reads, but it ships with bad blocks and grows more over time, so the software has to manage them. Some higher end routers use eMMC, which hides the NAND behind a controller. The same document points out that newer SoCs tend to keep the first stage bootloader on chip and support chain of trust booting.

RAM is usually one or two DDR3 or DDR4 chips; budget routers carry far less than flagship Wi-Fi 7 models.

Power, clocks and the rest

A DC barrel jack or USB-C input feeds switching regulators that make the core, memory and I/O voltages. Crystals provide reference clocks for the SoC and each radio. There are LEDs, a reset button, sometimes a WPS button, and almost always a serial console header on the board, often unpopulated, which engineers use during development and repair.

Component comparison table

How does the reference design model work?

Chipset makers do not just sell chips. For each SoC and radio family they publish a reference design: schematics, a board layout, a recommended bill of materials, antenna guidance, RF tuning tables and an SDK. The SDK is a full Linux build: a bootloader, a kernel with the chipset's drivers patched in, Wi-Fi drivers and firmware blobs, the packet engine's offload code, a toolchain and a build system, often with sample web pages.

A brand then has two options. It can design the product itself from the reference design, or it can hire an original design manufacturer (ODM) that has already built boards around that chipset. Either way, the board keeps the reference design's core: the same SoC, the same radio chips, the same memory interface routing and usually the same switch. What changes is the outline of the board, the antenna placement, the memory sizes, the number and speed of ports, the LEDs and the case.

That is why routers from different brands built on one chipset family often look nearly identical when opened, and why the FCC ID records for two brands' routers can show the same chips in the same positions. It is also why their firmware has the same skeleton. Under the brand's web interface and app sits the same SDK kernel, the same Wi-Fi driver and often the same versions of the same user space tools.

Why this matters for security

The reference design model has a direct effect on how fast a router gets patched.

1. A bug in the SDK kernel or Wi-Fi driver affects every brand that shipped that SDK. Each brand has to receive the fix from the chipset maker, merge it into its own tree and release its own update.
2. The SDK pins versions. If the chipset maker based its SDK on an older kernel branch, every product built on it starts life on that branch. Moving to a newer kernel usually means a new SDK release, and brands rarely port old products to it.
3. The chipset maker's driver code is often not merged upstream into the mainline Linux kernel. That means the community kernel maintainers do not maintain it, and only the chipset maker can fix it.

Open source firmware projects such as OpenWrt cut through part of this by supporting hardware with mainline or community drivers. OpenWrt describes itself in its 24.10 release notes as "a complete replacement for the vendor-supplied firmware of a wide range of wireless routers". Our stock versus open firmware post covers that trade off in detail.

How is the board manufactured and tested?

Bare board fabrication

A router board is a multilayer printed circuit board, and current Wi-Fi 6 and Wi-Fi 7 designs use more layers than older routers did. Inner layers are etched copper on glass reinforced epoxy, pressed together with prepreg sheets, drilled, plated through and finished. The RF traces from each radio to its front-end module and antenna connector are controlled impedance lines, usually 50 ohms, so the fabricator builds test coupons on the panel edge and measures them to prove the stackup came out as designed.

Surface mount assembly

The assembly line looks the same as for any other electronics product. Solder paste is printed through a laser cut stencil onto the pads. A solder paste inspection machine measures paste height and volume. Pick and place machines put down hundreds of parts per board, from tiny resistors to the SoC in a ball grid array package. The board passes through a reflow oven where the paste melts and wets each joint. Automated optical inspection checks polarity, alignment and visible joints, and X-ray inspection checks the hidden solder balls under the SoC, the radios and the memory. The metal RF shields are often placed in the same pass.

Programming the flash

Flash has to be written somewhere. There are three common approaches:

• The flash chips are programmed before assembly with a bootloader or a full factory image, by the distributor or a programming house, so the board can boot as soon as it powers up.
• A test fixture writes the image after assembly over SPI, JTAG or the SoC's serial recovery mode.
• A minimal bootloader is written first, and the test station pushes the full factory image over Ethernet.

The factory image is not always the image you will run. Many lines write a test firmware first, use it to calibrate and test the board, then write the shipping firmware at the end.

RF calibration

Every radio chain varies a little from unit to unit because of part tolerances in the front-end module, the crystal and the board. The test station connects cables to each antenna port, tells the radio to transmit at a set power and frequency, measures what actually comes out with a test instrument, and writes correction values. It does the same for receive.

Those values are stored per device. OpenWrt's flash documentation shows a classic example: on an older single SoC router, one partition named "art" (Atheros Radio Test) holds the Wi-Fi calibration data, and the page warns that if it is lost or damaged, the ath9k Wi-Fi driver will not start. On many other designs the same data lives in a partition called "factory". This is why any guide to reflashing a router tells you to back up these partitions first: they cannot be recreated without the factory calibration station.

Conducted and radiated tests

Two kinds of radio test happen:

• Conducted tests connect cables straight to the antenna ports and measure output power, occupied bandwidth, spurious emissions outside the band, frequency error and, for 5 GHz, dynamic frequency selection behavior when a radar signal is simulated. These are repeatable and cheap, so they run on every unit in some form on the production line.
• Radiated tests put the finished unit, with its real antennas and case, in an anechoic chamber and measure the field around it. These check the antenna gain the design assumes and unintended emissions from the digital parts. They run on samples during design and certification, not on every unit.

FCC certification

In the US, the FCC's equipment authorization page says that radio frequency devices "are required to be properly authorized under 47 CFR part 2 prior to being marketed or imported". There are two procedures, Certification and the Supplier's Declaration of Conformity; a Wi-Fi router is an intentional radiator and goes through Certification. The FCC lists the steps: determine the rules, determine the procedure, test at an authorized lab, obtain the approval, label the product, and keep records. The applicant needs a grantee code the first time it applies, files with a Telecommunication Certification Body (TCB), and the TCB issues the grant on the FCC's Equipment Authorization System.

The application contents are set by 47 CFR 2.1033. Among them: a block diagram showing all oscillator frequencies, a schematic for intentional radiators, a measurement report, and enough photographs to show the exterior, the construction, where components sit and how the chassis is assembled. That is why the FCC ID on the label leads, through the FCC's public database, to internal photos of many routers. For 5 GHz radios, the same section asks for "a high level operational description of the security procedures that control the radio frequency operating parameters".

That security description exists because of 47 CFR 15.407(i), which says: "All U-NII devices must contain security features to protect against modification of software by unauthorized parties." The rule asks makers to stop third parties reprogramming the device to operate outside its certified frequencies, power or modulation, and it lists electronic signatures in software among the acceptable means. This is a regulatory reason, separate from security, for router makers to sign firmware and lock the radio configuration.

The label rule in 47 CFR 2.925 requires the FCC ID to be printed after the words "FCC ID" in letters legible without magnification, or provided electronically where allowed. The grantee code at the start of the FCC ID identifies who applied, which can be a design manufacturer rather than the brand on the box.

What is in router firmware?

A typical stock router image, unpacked, contains the following layers. The order is the order in which they run.

Boot ROM and first stage loader

The boot ROM in the SoC reads the first stage loader from flash (or from an on-chip location) into internal SRAM and runs it. On ARM based SoCs that use Trusted Firmware-A, the first stages are BL1 and BL2, which set up DRAM and load the later stages. Trusted Firmware-A's trusted board boot design names the trust anchor as a Root of Trust Public Key (ROTPK) "or a hash of it", stored in trusted root-key storage registers on Arm's development platforms, with BL1 assumed to sit in ROM where it cannot be altered.

The bootloader

The second stage bootloader on most router designs is U-Boot or a vendor fork of it, sometimes very old. It initializes more hardware, reads its environment from a small flash partition, and loads the kernel. It also provides the recovery path you see when a router has a "TFTP recovery" or "web recovery" mode: if the main image fails, the bootloader can accept a new one over the network.

U-Boot's own documentation explains verified boot: the bootloader verifies every image it loads against a public key stored in its control device tree, and it describes a chain where U-Boot loads a signed kernel, which then uses dm-verity "to mount a signed root filesystem". Whether a given router turns this on is a product decision; the code has been in U-Boot for years.

The kernel and its drivers

Next comes the Linux kernel, with the chipset maker's drivers for the switch, the packet engine, the flash controller and the Wi-Fi radios. The kernel version is usually set by the SDK. The Linux kernel project's releases page lists the long term branches it maintains and when each is expected to stop: as fetched on 23 October 2026, 5.10 and 5.15 have a projected end of life in December 2026, 6.1 and 6.6 in December 2027, and 6.12 and 6.18 in December 2028. The same page says kernel developers "can provide no support" for distribution kernels, which are not hosted at kernel.org. A router SDK kernel is in that category: once it diverges from the long term branch, only the chipset maker and the brand can fix it.

The root filesystem and BusyBox

The root filesystem is usually SquashFS, compressed and read only, with a small writable area for settings. On NOR flash routers, OpenWrt layers a JFFS2 partition over the SquashFS root with OverlayFS, which its documentation describes as the project's default setup from the start. On NAND, UBI and UBIFS handle bad blocks and wear leveling.

Inside the root filesystem, almost every router uses BusyBox, a single binary that provides the shell and hundreds of small Unix tools (ls, ps, ifconfig, udhcpc, telnetd, httpd and so on). The BusyBox project's site lists 1.37.0 on 27 September 2024 and 1.38.0 on 13 May 2026, and OpenWrt 25.12.0, released on 5 March 2026, ships BusyBox 1.37.0. The BusyBox site also gives an email address for reporting GPL violations, which tells you how often it ends up inside closed products.

The network services

On top sit the services that make it a router:

• A DHCP and DNS server (OpenWrt 25.12.0 ships dnsmasq 2.91).
• An SSH server (dropbear 2025.89 in OpenWrt 25.12.0).
• The Wi-Fi authenticator, hostapd, which handles WPA2 and WPA3 (OpenWrt 25.12.0 uses a hostapd snapshot from August 2025).
• A firewall built on the kernel's netfilter.
• A TLS library for the web interface and the update client (OpenWrt 24.10 moved to mbedtls 3.6, which brought TLS 1.3 to default images).
• Often a UPnP or NAT-PMP daemon, a dynamic DNS client, a media server, a VPN server, a parental controls agent and a cloud management agent.

We quote OpenWrt versions because the project publishes them; stock firmware rarely does.

The web UI, app backend and update client

The brand's own code is a web management interface (often a CGI program or a small web server with a Lua, PHP or C backend), the API its phone app talks to, the cloud agent for remote management, and the update client. CISA and the FBI's January 2024 Secure by Design alert on small office and home office routers singled out the web management interface: it asks makers to "eliminate exploitable defects" in it, to automate updates, and to put the management interface on LAN side ports by default.

The vendor SDK, as a whole

Put together, the SDK supplies the bootloader, kernel, drivers, radio firmware blobs and often the toolchain and base user space. The brand adds the web UI, app and cloud integration, and its own update logic. The result is a firmware image whose largest part, by lines of code, is open source written by other people, pinned to versions chosen by a chipset maker, and shipped by a brand that may not have the source for the closed driver pieces.

Why do router images carry so many old open source components?

Three forces keep old components in router images.

The SDK pins them. A product is built on one SDK release. The brand fixes bugs in its own code, but the kernel, the drivers and much of user space stay at the SDK's versions for the life of the product. Moving a shipped product to a new SDK is a full re-validation, including RF testing, and the business case for doing that on a two year old router is weak.

Flash is small and the build is fragile. On a 16 MB NOR flash router every kilobyte counts. Updating a library can grow the image past the partition. OpenWrt's flash documentation notes that its image builder makes images smaller than the partition "by an arbitrary margin" so they can be flashed safely, which shows how tight the budget is.

The closed pieces tie the kernel down. A Wi-Fi driver or packet engine module distributed only as a binary is built for one kernel version. Moving the kernel means getting new binaries from the chipset maker, which may not exist for an older chip.

The result is predictable. A router sold in 2026 can carry a kernel whose upstream long term support ends in December 2026, user space tools that are several releases behind, and radio firmware that nobody outside the chipset maker can inspect.

Worked example 1: the support gap in years

Say a router reaches shelves in March 2026 on an SDK built on the 5.10 kernel branch, and the brand promises five years of security updates, to March 2031.

• The 5.10 branch was released on 13 December 2020 and has a projected end of life of December 2026, per kernel.org.
• So upstream kernel maintainers stop backporting fixes nine months after launch.
• For the remaining time, from January 2027 to March 2031, about 51 months, every kernel fix has to be found and backported by the chipset maker or the brand, without the long term branch to pull from.

Had the same router launched on 6.12 or 6.18 (both projected to December 2028), the unsupported tail would shrink to about 27 months. That is the arithmetic behind the advice to check a router's kernel version before you trust its support period.

Worked example 2: a flash budget

OpenWrt's flash layout page shows the partition map of a small travel router with 8,192 KiB of NOR flash. The bootloader takes 192 KiB, its environment 64 KiB and the factory calibration partition 64 KiB, leaving the firmware partition at 7,872 KiB (8,192 minus 320). Inside that, the kernel takes about 1 MiB, the read only root filesystem about 2 MiB and the writable overlay about 4.5 MiB.

Another example on the same page shows how to read the map from a live system:

cat /proc/mtd
dev:    size   erasesize  name
mtd0: 00020000 00010000 "u-boot"
mtd1: 00140000 00010000 "kernel"
mtd2: 00690000 00010000 "rootfs"
mtd3: 00530000 00010000 "rootfs_data"
mtd4: 00010000 00010000 "art"
mtd5: 007d0000 00010000 "firmware"

The sizes are hexadecimal bytes. Converting them:

The kernel and rootfs add up exactly to the firmware partition (0x140000 plus 0x690000 equals 0x7d0000), and the bootloader, firmware and art partitions add up to 0x800000, which is 8 MiB. On a device like this, a newer kernel that is 200 KiB bigger can mean dropping a feature, which is one more reason brands keep old versions.

What do GPL source releases reveal?

Version 2 of the GNU General Public License, which covers the Linux kernel, BusyBox and U-Boot, lets a company distribute binaries only if it also does one of three things in section 3: ship the complete source alongside, include "a written offer, valid for at least three years" to provide it at no more than the cost of copying, or pass on the offer it received (that last option is for noncommercial redistribution). The license defines complete source as all the source for every module, plus interface definition files and the scripts that control compilation and installation.

So most router makers publish a GPL code download page or answer source requests. A GPL tarball is the most honest component list you will get for a stock router. It tells you:

• The exact kernel version and how far the vendor tree has drifted from upstream (compare the Makefile version and the patch set).
• The BusyBox version and its build configuration, which shows which applets, such as telnetd, are compiled in.
• The versions of other GPL components: the bootloader, iptables or nftables, and often more.
• Which pieces are absent: closed kernel modules for Wi-Fi or packet offload appear only as binaries or not at all, and permissively licensed components such as dnsmasq or OpenSSL may not be included because their licenses do not require it.

A source release cannot show you what the brand did not have to publish, and it may not match the exact binary on your device if the company published it for an earlier firmware. It is still a better inventory than nothing, and you can scan it like any other source tree.

How do secure boot, signed images and automatic updates work on routers?

The chain of trust

Secure boot on a router has the same shape as on a phone or a server:

1. At the factory, the hash of the manufacturer's public key is burned into OTP fuses, and a fuse is set that tells the boot ROM to refuse unsigned code.
2. At power on, the boot ROM loads the first stage loader and checks its signature against the fused key hash. If it fails, the device does not boot (or falls into a recovery mode that also only accepts signed images).
3. Each stage verifies the next. Trusted Firmware-A uses X.509 v3 certificates to carry the keys and hashes for each stage. U-Boot verifies a signed FIT image containing the kernel and device tree.
4. The kernel can verify the root filesystem block by block with dm-verity, so a modified SquashFS will fail to read.

U-Boot's FIT signature documentation explains a detail that decides whether this works. The public key cannot live in the signed image, "since it would be easy to alter", so U-Boot stores it in its own control device tree. A key node can carry a "required" property, set to "image" to force verification of every image or to "conf" to verify the selected configuration; only required keys are normally checked by the boot process. The documentation also warns that with required signatures the legacy unsigned image format is disabled by default. A bootloader built with signature support but without a required key, or with the legacy format left on, can boot unsigned kernels.

Anti-rollback

Signing alone does not stop an attacker, or a confused user, from installing an older signed image with a known bug. That is what rollback protection is for. Trusted Firmware-A exposes platform hooks for non-volatile counters (plat_get_nv_ctr and plat_set_nv_ctr in its porting guide) that let each image carry a version number the device will not go below. NIST IR 8425A, the router profile NIST published in September 2024, makes this explicit: it asks for measures to keep firmware up to date, including protection against rollback attacks, for example "not allowing the rollback of firmware to a version with known vulnerabilities".

Signed update images

The update file itself is usually a container with a header, a kernel and a root filesystem, signed by the vendor. The router's update client downloads it, checks the signature (and often a version and model field), writes it to the inactive partition on dual image designs or over the running image on single image designs, and reboots. NIST IR 8425A asks that each router component can receive, verify and apply only signed updates, and suggests that ISP leased routers could carry a second signature from the ISP, with the router applying an update only when both signatures verify. It also asks that a failed update leaves the product able to return to a usable state.

OpenWrt shows how these ideas look on an open project. Its public keys page lists GnuPG keys used "to verify the integrity of firmware image downloads", plus separate keys for package signing (usign for older releases, apk keys for the newer package manager that OpenWrt 25.12 switched to). Its Attended Sysupgrade clients compute a SHA-256 of the image built by the server and compare it with the checksum in the build metadata before installing, and refuse to install on a mismatch. The project is clear that its web Firmware Selector "does not (cannot)" do this check for you, so a manual download needs a manual checksum.

Automatic updates

CISA and the FBI asked SOHO router makers in January 2024 to change defaults so that updates happen automatically. NIST IR 8425A accepts either automatic updates or consistent notification to the customer that an update is available. In practice there are three patterns on home routers:

• Fully automatic: the router checks a vendor server on a schedule, downloads a signed image and installs it at night. This is the default on many app managed mesh systems.
• Notify and click: the router or app tells you an update exists and you approve it.
• Manual only: you download the image from the vendor site and upload it in the web UI. Many older and budget routers still work this way.

The danger in each is different. Automatic updates are only as good as the signing key's protection and the server's integrity. Manual updates depend on the owner noticing. And any router past its support period gets no updates at all.

Secure boot and update comparison

What do the US Cyber Trust Mark, the UK PSTI regime and the EU CRA require?

United States: FCC equipment rules and the Cyber Trust Mark

The binding US rules for routers today are the radio rules above: certification under Part 2 and Part 15, and the U-NII software security requirement in 15.407(i).

The U.S. Cyber Trust Mark is a separate, voluntary labeling program. The FCC's program page says it sought comment in August 2023 and adopted the rules that frame the program in March 2024. A product carrying the mark will have a QR code linking to a registry that shows, among other things, how to change the default password, whether updates are automatic, and the product's minimum support period end date, or a statement that the manufacturer does not support it.

Two details matter for router buyers. First, the FCC's FAQ says the program starts with wireless consumer IoT products and "does not include personal computers, smartphones, and routers". Second, the program's administration has changed hands: the FCC page records that the first lead administrator withdrew effective 19 December 2025, a new lead administrator was named effective 13 April 2026, label administrators and a filing window were announced on 11 August 2026, and accreditation bodies were recognized on 28 September 2026. The FCC says it will announce when the program is ready to accept product applications. As of this post, you should not expect a Cyber Trust Mark on a home router.

The router specific work happens at NIST. NIST IR 8425 (September 2022) set the consumer IoT baseline the program builds on, and NIST IR 8425A (September 2024) adds a consumer-grade router profile. Among its requirements: disable remote management from the WAN by default and confine management to LAN interfaces; accept only signed updates; keep firmware up to date with rollback protection; and preserve configuration through updates, reverting to a usable state if one fails. It also lists ideas beyond the baseline, including machine readable asset identifiers that include firmware version.

United Kingdom: the PSTI regime

The UK's product security regime came into effect on 29 April 2024, under Part 1 of the Product Security and Telecommunications Infrastructure Act 2022 and the 2023 security requirements regulations, which were signed into law on 14 September 2023. Routers sold to UK consumers are relevant connectable products. GOV.UK's guidance sets out three requirements:

1. Passwords must be unique per product or set by the user. Unique passwords must not be based on incremental counters, public information or unique product identifiers such as a serial number (unless derived with accepted cryptography), or be otherwise easily guessable.
2. Reporting security issues: the manufacturer must publish how to report security issues and when the reporter can expect an acknowledgment and status updates.
3. Minimum security update period: the manufacturer must publish how long security updates will be provided, with an end date, understandable to a reader without technical knowledge.

The guidance names the Office for Product Safety and Standards as the enforcer from 29 April 2024, and points to ETSI EN 303 645 as the baseline standard the requirements come from. In factory terms, requirement 1 is why the provisioning step in our table generates a unique admin password and Wi-Fi passphrase per unit and prints them on the label.

European Union: the Cyber Resilience Act

The Cyber Resilience Act, Regulation (EU) 2024/2847, entered into force on 10 December 2024. According to the European Commission, its main obligations apply from 11 December 2027, and its reporting obligations have applied since 11 September 2026. Products that meet it will carry the CE marking.

For a router maker, the Commission's summary highlights:

• Essential requirements for design, development and maintenance, plus vulnerability handling requirements in Annex I.
• A declared support period, during which vulnerabilities must be handled; its end date, "including month and year", must be clear at the time of purchase.
• Reporting of actively exploited vulnerabilities and severe incidents to the national CSIRT and ENISA through the CRA Single Reporting Platform: an early warning within 24 hours, a main notification within 72 hours, and a final report no later than 14 days after a fix or mitigation is available for an exploited vulnerability.
• Conformity assessment by category. The Commission's conformity assessment page lists routers as an example of "important products". For important products in class I, self-assessment is allowed only if the maker applies harmonised standards, common specifications or a European certification scheme; otherwise a notified body must assess the product. Class II and critical products need third party assessment. The technical descriptions of each category are in Implementing Regulation (EU) 2025/2392.

Because the reporting duties are already live, a router maker with an exploited vulnerability in a product on the EU market today has a 24 hour clock. That makes the SDK problem above more expensive: a maker that does not know which kernel and drivers are in which product cannot report, let alone fix, on that timeline.

Regulation comparison

How do you check your own router's firmware, update channel and exposed services?

The steps below are read only checks. They do not change your router. Where a step mentions flashing or partition backups, read the warning first.

Step 1: find the exact model, hardware revision and FCC ID

Look at the label on the bottom. Note the model, the hardware version (often "V2" or "Rev. B", which can mean a different chipset), the serial and the FCC ID. Searching the FCC ID on the FCC's equipment authorization database shows the grant date, the frequency ranges and, for many routers, internal photos that let you identify the SoC and radio chips.

Step 2: read the firmware version and kernel

In the web UI, the status or system page shows the firmware version and often the build date. If the router gives you an SSH or serial shell (OpenWrt always does; some stock firmware does), read more:

# On the router (OpenWrt or a stock firmware with a shell)
cat /etc/openwrt_release 2>/dev/null
uname -a
busybox | head -1
cat /proc/mtd

On OpenWrt, ubus call system board prints the model, kernel and release in one JSON object. Compare the kernel version with the long term branches on kernel.org's releases page. If the first two numbers are not on that list, the kernel's upstream support has ended.

Step 3: find the update channel and support period

Check, in the web UI or app:

• Whether automatic updates are on, and when the last check happened.
• The update history, if shown.
• The maker's published security update period or end of support date. In the UK this must be published under PSTI; on the EU market it must be shown at purchase once the CRA's main obligations apply. If you cannot find it, treat the support as unknown.

On OpenWrt, a release's end of life is announced on the project's releases page. For example, the OpenWrt 25.12.0 release notes say the project "will not provide security updates for OpenWrt 24.10 after September 2026".

Step 4: list the services listening on the router

From a shell on the router:

# Which processes listen on which ports (BusyBox netstat or ss)
netstat -tulpn 2>/dev/null || ss -tulpn

Look for anything you did not expect: telnet, a remote management web port on all interfaces, a UPnP daemon, a media server, an FTP or SMB service for an attached USB drive.

Step 5: scan the router from the LAN and from outside

From a laptop on your LAN, with the router at its usual address:

# From a computer on your own LAN; scan only devices you own
nmap -sT -Pn 192.168.1.1
nmap -sU -Pn -p 53,67,1900,5351 192.168.1.1

Then repeat the TCP scan against your public IP address from a network outside your home, for example a phone hotspot. NIST IR 8425A recommends disabling remote access from the WAN by default; if the web UI, SSH or telnet answers from outside and you did not turn on remote management, turn it off. Only scan addresses you own or have permission to test.

Step 6: check UPnP port mappings

If UPnP is on, list the mappings applications have opened:

# miniupnpc client, from a LAN computer
upnpc -l

Remove mappings you do not recognize and turn UPnP off if you do not need it.

Step 7: verify any firmware file before installing it

If you install updates by hand, verify the file first. For OpenWrt, the project's documentation shows downloading the release's sha256sums file next to the image and checking it:

# On the computer where you downloaded the image
sha256sum -c sha256sums 2>/dev/null | grep OK

The filename should be listed with "OK". For stock firmware, compare against the checksum on the vendor's download page if one is published, and download only from the vendor's own site.

Step 8: if you plan to reflash, back up the factory partitions first

Warning: the next block reads raw flash partitions. Writing to these partitions, or flashing the wrong image, can permanently disable the Wi-Fi radio or brick the router. Confirm the partition names on your own device first with cat /proc/mtd, and copy the backups off the router before doing anything else.

# Check the partition names on THIS device first
cat /proc/mtd
# Then read (not write) the calibration and bootloader partitions to RAM,
# using the mtd numbers you just confirmed, and copy them off the router
dd if=/dev/mtd4 of=/tmp/art.bin
dd if=/dev/mtd0 of=/tmp/u-boot.bin

Then copy the files to your computer with scp. On OpenWrt, the documented upgrade command is sysupgrade -v with the image path; by default it keeps settings, and its documentation explains when not to keep them. Read the device's wiki page before flashing.

Step 9: record what you found

Write down model, hardware revision, FCC ID, firmware version, kernel version, BusyBox version, update mode, support end date and open ports. If you run more than one router, or manage them for a small office, this record is a basic hardware and firmware inventory, and it is the list you will need the day a router advisory lands.

Common mistakes

• Assuming the brand writes the firmware. Most of it comes from the chipset SDK and open source projects. A brand's advisory often follows a chipset maker's fix by weeks or months.
• Treating "latest firmware" as "supported". A fully updated router can be past its support period, running an image years old. Check the end date.
• Ignoring hardware revisions. Two routers with the same model name and different revisions can use different chipsets and different firmware. Download the image for your exact revision.
• Leaving remote management on. CISA, the FBI and NIST all point to WAN facing management interfaces as a main route into SOHO routers. Turn remote management off unless you need it, and use a VPN into the LAN if you do.
• Flashing without backups. The calibration partition is unique to each unit. Without it, Wi-Fi may not work after a bad flash, and no download can replace it.
• Skipping checksum checks on manual downloads. OpenWrt says its web Firmware Selector cannot check the image for you. Use the published checksums or signatures.
• Believing a signed image means a safe image. Signing proves who built it. It does not prove that the kernel inside is patched.
• Reading a GPL tarball as a full bill of materials. It shows GPL components. Closed drivers and permissively licensed libraries may be missing.
• Expecting a Cyber Trust Mark on a router today. The FCC says the program does not include routers at first; look for the support period and update information instead.
• Forgetting the ISP router. If your ISP supplied the router, it may control updates. Ask the ISP what its update policy and support period are.

FAQ

What chips are inside a Wi-Fi router?

A networking system on chip with CPU cores and a packet engine, one or more Wi-Fi radio chips (one per band, or integrated in the SoC for 2.4 GHz), an Ethernet switch, flash memory for the firmware, a RAM chip, and front-end modules that amplify and filter the radio signal for each antenna.

Why do routers from different brands look the same inside?

Chipset makers sell a reference design and an SDK with each chip family. Brands, or the design manufacturers they hire, keep the core of that design and change the board shape, antenna layout, memory, ports and case. The software underneath also comes from the same SDK.

What operating system do home routers run?

Almost all run Linux, built from a chipset maker's SDK, with BusyBox for the shell and basic tools, a bootloader such as U-Boot, and the brand's own web interface and app backend on top. Some use other embedded operating systems, but Linux is the norm.

How do I find out what chipset my router uses?

Search the FCC ID from the label in the FCC's equipment authorization database. Many grants include internal photos showing the chip markings. Open source firmware projects also list chipsets on their device pages.

Does my router update itself automatically?

It depends on the model and settings. Many app managed and mesh systems update automatically by default; many budget and older routers need you to check and install by hand. Look in the web UI or app for an automatic update setting and the date of the last check.

How long will my router get security updates?

Look for the maker's published support period or end of support date. In the UK, makers of consumer connectable products must publish it under the PSTI regime. Under the EU CRA, the end date must be shown at the time of purchase once the main obligations apply in December 2027.

Is open source router firmware safer than stock firmware?

It can be, because projects such as OpenWrt publish component versions, sign their releases and announce end of life dates. It is not automatic: it depends on the device's support and on you applying updates. See our comparison of open source and stock router firmware for the full trade off.

What is a GPL source code release for a router?

Router makers that ship GPL licensed software, such as the Linux kernel and BusyBox, must provide the corresponding source code or a written offer for it. The release shows which versions of those components the firmware contains, though it may leave out closed drivers and permissively licensed libraries.

Does secure boot stop router hacking?

Secure boot stops a router from booting firmware that the maker did not sign. It does not stop attacks on bugs in the signed firmware, such as a flaw in the web interface, and without rollback protection an attacker may be able to install an older signed version with known bugs.

Do routers need FCC certification?

Yes. A Wi-Fi router is an intentional radiator and must be certified through a Telecommunication Certification Body before it is marketed or imported into the US. 5 GHz radios must also include security features that stop unauthorized software from operating the radio outside its certified parameters.

Where Safeguard fits, honestly

Safeguard does not analyze router hardware, scan firmware images, generate hardware bills of materials or manage devices, and its models are single purpose security models, not tools for radio or electronics work. The fit is narrower and still real. The router's firmware is a software supply chain of open source components, and the code around it is often software you do build: a router maker's web UI and app backend, the cloud service the router talks to, the build scripts and containers that produce images, and in a small office the scripts and tools that manage a fleet. Safeguard scans those repositories, container images and SBOM files for known vulnerable components with safeguard scan, shows which projects contain a given component and version, applies policies and gates, and can open fix pull requests for dependency upgrades when you turn autonomous remediation on (it ships switched off). If you have a router vendor's GPL source tree or an SBOM for an image you build, you can run a directory or SBOM scan against it like any other project. Safeguard does not replace the chipset maker's or brand's firmware update; when the vulnerable code is in a closed driver or the vendor's image, the fix still has to come from them.

Fix it without waiting for upstream

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation covers eight categories, including dependencies, licenses, security posture and findings. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.

3. Gold Registry: start from components that are already fixed

registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. This fork and patch flow is in early access today, so ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

The first demo is a real Safeguard CLI session. It installs the CLI, opens the interactive terminal and asks it to fix a lodash CVE in a repository; the assistant reads the finding and advisory, asks before each command, edits package.json to lodash 4.17.21, runs npm install and npm test with your approval and pushes nothing. The same flow fits a router management web UI, a companion app backend or a provisioning tool your team maintains.

Click through it at your own pace, or open it full screen.

The second demo sets up the Safeguard runner on your own machine, approves it with its device code and then scans from the terminal. That suits a team that builds firmware or companion software on its own build hosts and wants the scan to run where the build runs, for example against a source tree or an SBOM file it already produces.

Click through it at your own pace, or open it full screen.

The third demo connects Claude to the Safeguard MCP server with OAuth and chooses which tools Claude can use. If your team already asks Claude questions about its projects, this is how the same conversation can look up which projects carry a vulnerable component after a router related advisory names one.

Click through it at your own pace, or open it full screen.

To try it on your own repositories, download Safeguard and follow the CLI documentation.

Quick check

Sources

• FCC, Equipment Authorization
• eCFR, 47 CFR 2.1033, Application for certification
• eCFR, 47 CFR 2.925, Identification of equipment
• eCFR, 47 CFR 15.407, General technical requirements (U-NII)
• FCC, U.S. Cyber Trust Mark
• NIST, IR 8425A, Recommended Cybersecurity Requirements for Consumer-Grade Router Products (September 2024)
• NIST, IR 8425A full text (PDF)
• NIST, IR 8425, Profile of the IoT Core Baseline for Consumer IoT Products (September 2022)
• CISA, Secure by Design Alert: Security Design Improvements for SOHO Device Manufacturers (31 January 2024)
• GOV.UK, The UK Product Security and Telecommunications Infrastructure (Product Security) regime
• European Commission, Cyber Resilience Act
• European Commission, Cyber Resilience Act: summary of the legislative text
• European Commission, Cyber Resilience Act: conformity assessment
• European Commission, Cyber Resilience Act: manufacturers
• OpenWrt, The OpenWrt Flash Layout
• OpenWrt, Upgrading OpenWrt firmware (sysupgrade)
• OpenWrt, Upgrade using Attended Sysupgrade
• OpenWrt, OpenWrt Public Keys
• OpenWrt, OpenWrt 24.10.0 release notes (6 February 2025)
• OpenWrt, OpenWrt 25.12.0 release notes (5 March 2026)
• OpenWrt, Release builds
• U-Boot documentation, FIT Signature Verification
• U-Boot documentation, U-Boot Verified Boot
• Trusted Firmware-A documentation, Trusted Board Boot
• GNU Project, GNU General Public License, version 2
• The Linux Kernel Archives, Releases
• BusyBox project home page and release news

Last reviewed: 23 October 2026.