The router default-password problem, measured: what 277 manufacturer-verified models actually show

Headline finding

Of the 277 router, mesh, gateway and access-point models ssid.ai tracks (each credential type cited to the manufacturer's own documentation, not scraped or guessed), 81 (29%) still ship a universal default password, the exact pattern the UK's PSTI Act and the EU's Cyber Resilience Act are built to eliminate.

The surprising part isn't the 29%. It's who it belongs to. Mass-market consumer brands have mostly already moved off the pattern: ASUS ships a static default on 1 of its 20 tracked models (5%), TP-Link on 3 of 28 (11%). The brands still shipping it on nearly everything are the SMB and prosumer networking vendors — Peplink (9 of 9 models, 100%), DrayTek (6 of 6, 100%), Netgate/pfsense (5 of 5, 100%) and Linksys (9 of 10, 90%). Netgear, still a mass-market name, is the one big-box outlier at 46% (12 of 26).

The devices most likely to still hand an attacker admin/admin in 2026 aren't the ones a typical household buys off a shelf. They're the ones a small business's IT contractor installs and never touches again.

Why this still matters

Default credentials becoming a security problem isn't new. Mirai, the botnet that turned IoT devices into a DDoS weapon at scale, spread through 2016 mainly by trying a fixed list of 61 factory default username/password pairs over Telnet against any device that would answer, root/xc3511 chief among them (CSO Online). Its source code leaked that same year, and its descendants have defined the IoT-botnet pattern ever since.

The 2026 numbers show that pattern is current, not historical. In March 2026 the US Department of Justice announced the disruption of four IoT botnets, Aisuru, Kimwolf, JackSkid and Mossad, which had together compromised more than 3 million routers and IoT devices worldwide (Krebs on Security). Aisuru itself, according to Germany's federal cybersecurity agency (BSI), spreads in part by “automatically scanning the internet for IoT devices with weak or factory-default credentials, particularly via the Telnet service,” alongside known vulnerabilities in specific router brands and a 2025 supply-chain compromise of a TotoLink firmware update server (BSI). Microsoft Azure absorbed a 15.72 Tbps, 3.64 billion-packet-per-second DDoS attack attributed to Aisuru on 24 October 2025, disclosed by Microsoft on 17 November 2025 as the largest attack Azure has recorded to date (BleepingComputer).

None of this proves any specific model on ssid.ai's own 81-model static-default list has been used in a real attack, and this report doesn't claim that. It shows the underlying pattern, a device answering to a documented, guessable default, remains raw material for large-scale botnets a decade after Mirai. A separate 2025 survey of 3,242 UK broadband users by Broadband Genie (fieldwork ran April through October 2025) found 81% had never changed their router's admin password (broadband.co.uk). That number describes user behavior after purchase, not what a manufacturer ships in the box. ssid.ai's dataset measures the second thing; it says nothing about the first.

Methodology

Every credential type in this dataset (set-on-setup, label-unique, app-only, or static) is compiled directly from a manufacturer's own official documentation: their own domain, or an official manual PDF. Nothing is scraped from a third-party password list, nothing is guessed from a device's release year, and nothing ships without a source URL attached to the specific model. A model that can't be verified this way is excluded, not filled in with a best guess.

Of the 277 tracked models, 187 (68%) are rated “high confidence” and 90 (32%) “medium” — no model in the live dataset carries a “low confidence” tag; anything that shaky doesn't ship. The underlying sources table holds 7,758 citation rows across 195 distinct source URLs (the count is higher than the URL count because the same manufacturer page gets re-verified on repeat compile runs, and each verification is logged, not just the first one). All 277router-credential entries carry a manufacturer source citation, though the citations aren't all unique to one model — 195 distinct URLs across 277 entries means some manufacturer pages (a shared legacy-router support article, a single FAQ that covers a product line) are cited for more than one model.

Since 2026-07-27, live compile runs also submit newly-verified or changed source pages to the Wayback Machine at verification time, so the claim “the manufacturer's page said X on this date” becomes independently checkable rather than something ssid.ai simply asserts. This is new: as of this data pull, only 6 of 6,984 device_versions rows and 20 of 39,898oui_history rows carry an archived snapshot. The mechanism works — it's just early, and a full historical backfill hasn't run yet. Treat the archive coverage as a forward-looking guarantee, not a retroactive one.

Coverage itself has grown quickly and recently: the router directory held 29 models on 2026-07-11, 211 by 2026-07-15, and 277 as of this compile run — a live, continuously-run process, not a one-time snapshot.

One licensing note in the interest of full transparency: the router-credential directory (277models) is compiled entirely from each manufacturer's own primary documentation and carries low legal risk under Feist-style factual-compilation doctrine. The separate MAC/OUI vendor dataset (cited below for one narrower finding) is sourced from IEEE's public OUI registry; IEEE has never asserted copyright over it but has, in at least one documented case, told a third party it does not authorize local redistribution and prefers live lookups. That question isn't resolved here — it's flagged for accuracy, not because it changes the router-credential findings below, which don't depend on the OUI data.

The current state

By credential type, across all 277 tracked models

By device category

Mesh systems are the cleanest category by a wide margin — only 1 of 42 tracked mesh models ships a static default. That tracks with mesh being a newer product category, mostly launched after Mirai made “admin/admin out of the box” a well-known liability; 55% of tracked mesh models are app-only (Google Nest Wifi, eero, and similar) with no web login to attack at all.

Standalone access points are the opposite: 8 of the 11 we track (73%) still ship a static default. The sample is small enough that a handful of new models could move the number a lot, but it's consistent with these being aimed at network administrators who are expected to change the password as part of setup rather than at a walk-up consumer.

By brand — the full spread (4+ tracked models, sorted by static share)

The full list of all 81 currently-static models (brand, exact model, username, password, and manufacturer source URL for each) is public at ssid.ai/compliance.

What's actually changing

This is where honesty matters more than a good story. ssid.ai started append-only versioning of router credential data on 2026-07-11 and has run 28 distinct compile passes through 2026-07-30, a 19-day observation window. In that window, across 6,984 version rows covering all 277 currently-tracked models, there have been zero real credential-policy change events. Every row is either added (277 rows, the first time each model entered the dataset) or verified_unchanged (6,707 rows, a model checked again with its documented credential type unmoved).

That's the expected result at this timescale, not a disappointing one. A manufacturer changing a documented default-credential policy is a slow, deliberate firmware or support-doc decision, not something that happens every few weeks across a 277-model sample. Reporting “zero events in 19 days” honestly, instead of padding it with something that looks like a trend, is the point of building this as a continuous record instead of a one-time compilation. A vendor rewriting a support page to describe forced setup instead of admin/password (in either direction) could land any day, and this is the only system positioned to catch it with a timestamp and an archived source — there's no way to backfill that catch after the fact. The mechanism is running; it just hasn't had a real event yet.

The parallel OUI-registry history (a different table, tracking IEEE's public vendor-assignment registry rather than router credentials) has been running longer (since 2026-07-17) and did catch real change events, which is useful as a proof that the append-only mechanism actually works when something real happens upstream:

• 2026-07-26 — Four Cisco Meraki-assigned OUI blocks (847D7E, 9C4DC2, 1C84A6, 1C2226) reassigned from "Cisco Meraki" to "Cisco Systems, Inc" in IEEE's registry — all four the same day.
• 2026-07-23 — One OUI block (F0DB30) renamed from "Yottabyte" to "Verge.io" in IEEE's registry.

Being transparent about the data also means flagging what looks like noise rather than counting it as signal. Of 29total “renamed” events logged in this window, 24 come from just two OUI prefixes, 24 of 29 'renamed' events come from just two OUI prefixes (0001C8, 080030) toggling between two organization-name strings on nearly every daily IEEE fetch — almost certainly an artifact of IEEE's own published registry file, not real repeated reassignment. We're logging it and flagging it rather than reporting “29 vendor renames” as if they were all real. Only 5 of 29 rows, across 5 distinct OUI blocks, describe a change we're confident actually happened.

The regulatory backdrop

Two overlapping regimes are why credType isn't just a UX label.

UK PSTI Act. The Product Security and Telecommunications Infrastructure (Security Requirements for Relevant Connectable Products) Regulations 2023 came into force on 2024-04-29. The operative language requires that a password be either unique per product or set by the user, and explicitly bars passwords “based on incremental counters,” “derived from publicly available information,” or otherwise “guessable in a manner unacceptable as part of good industry practice.” In ssid.ai's schema, static is exactly the pattern this bans; set-on-setup and label-unique are the compliant patterns. Enforcement sits with the UK's Office for Product Safety and Standards (OPSS), which has said it will take a risk-based approach; maximum penalties run to £10 million or 4% of global revenue. We found no documented case of OPSS having taken public enforcement action against a specific router vendor for this provision — see “Open questions” below.

EU Cyber Resilience Act.Manufacturers' mandatory vulnerability and incident reporting obligations to ENISA (via the CRA Single Reporting Platform) begin on 2026-09-11 — 24 hours for early warning of an actively-exploited vulnerability, 72 hours for the full notification, 14 days after a fix is available for the final report. That deadline applies to products already on the market, not just new ones. Maximum fines run to €15 million or 2.5% of global turnover.

Neither regime currently publishes a per-model public registry of which routers comply and which don't — the UK ban and the EU reporting mandate both create the legal requirement, but nobody in government is tracking, model by model, who's actually still shipping the banned pattern. That's the gap this dataset is positioned to describe, without claiming to be a legal compliance verdict: some tracked units predate PSTI entirely, or are sold outside jurisdictions where either law applies, and credType measures documented behavior, not legal status.

What this means

For security researchers and journalistswho want a specific, dated, sourced number instead of “many routers still ship default passwords”: 29% of 277 manufacturer-verified models, broken out by brand and category above, each with its own citation. That's a starting point for further work, not an endpoint — 277 models is a meaningful sample but nowhere near exhaustive of what's actually deployed in the field.

For anyone buying network gear for a small business or a technically unsupervised environment (the segment where this pattern concentrates): the brands to check credentials on by name, based on this data, are Peplink, DrayTek, Netgate and Linksys. A documented static default is the norm across their current lineups, not a rare exception, so the password needs changing at setup rather than assumed already unique. This is a data point about what ships out of the box, not a verdict on the products themselves.

For other developers and researchers building on this space: the credential data (ssid.ai/routers/*), the compliance aggregation (ssid.ai/compliance), and MAC/OUI vendor lookups are available via ssid-mcp and the API — every claim traces to a manufacturer source URL, which is the thing to check before trusting any third-party default-password list, including this one.