Methodology
This site publishes verdicts about named companies' named products, so it owes you the rules. Everything below is read from the running configuration rather than written out by hand: if the thresholds change, this page changes with them.
Verdict engine lifecycle-1 · vendor scorecards
scorecard-1
What each verdict means
- Actively updated firmware is arriving about as often as it always has
- Slowing down updates are coming less often than this product's own history
- Gone quiet no firmware for long enough to stand out against its own record
- End of support the vendor has said support is over
- Never updated shipped and sold, and no firmware has ever been published for it
- Not enough evidence we looked and will not guess — the reason is recorded below
“Not enough evidence” is a statement about our evidence, never about the product. Every such verdict records the specific reason, and the device page prints it.
How “gone quiet” is decided
Vendors almost never announce the end of support for consumer hardware — they simply stop. So there is no event to detect, and the verdict is a statistical claim about a product departing from its own habit: we model how often it has historically received firmware, then measure the silence since the last release against that.
- Active — silence up to 1.5× the product's own median gap.
- Slowing — up to 3.0× that gap.
- Gone quiet — beyond it.
- Absolute ceilings sit over those multiples. Past 365 days nothing reads active, and past 730 days nothing reads better than quiet, however slowly its vendor has always moved. A cadence model alone grades a vendor against its own bad habit; two years without a patch is the finding, not a baseline.
- A cadence needs 3 releases. Below that only absolute silence is sayable, at low confidence.
- “Never updated” needs a known launch date and 365 days since it.
- High confidence needs 5 releases whose gaps are regular, and dates the vendor published to the day.
How the transparency score is weighted
Four components, and any that nobody has been in a position to measure is dropped rather than scored zero — the remaining weights are renormalised and the score is published with the share of weight that survived.
- 0.4 — publishes a firmware history for the range it sells
- 0.2 — dates its releases
- 0.2 — says what changed
- 0.2 — says it in words that mean something
Where the catalog comes from
The catalog is the denominator: the firmware history says what got patched, the catalog says what exists, and the gap between them is the measurement. So it matters who assembled it. A vendor's own list quietly drops what it has stopped selling. A community hardware registry is organised around which devices people want to run their own firmware on, which selects for the routers enthusiasts buy and against the cheap, locked-down, ISP-supplied and IoT gear — the population where abandonment is worst. A catalog drawn mostly from one of those is a statistic about that list's taste, so the mix is published rather than the total.
- NETGEAR product sitemap — 328 products, 317 of them in no other catalog. The vendor's own list of its own products.
- OpenWrt device registry — 313 products, 302 of them in no other catalog. Independent of any vendor we measure.
- 0 of 630 products are in no catalog at all — we know they exist only because a vendor published firmware for them, which is the one way of finding a product that can say nothing about the products nobody published firmware for.
What counts as evidence
Every published fact traces to a page we fetched and kept, byte for byte, before any
parser read it. Device pages link to those copies; each carries the address, the time we
fetched it and the sha256 of its contents, so a claim can be checked after the vendor
edits the original. Nothing derived is presented as observed: a support end date we
calculated is marked estimated, and a support life measured from the first firmware we
saw is printed with a ≥.
What this dataset cannot currently say
Limitations of the published data are part of the method, not a footnote to it.
- 630 of 630 products cannot be measured at all — no firmware source has read a page about them, whether because their vendor's history is closed to us or because our crawl has not reached that box. Their verdicts read “not enough evidence”, and it would be wrong to read that as abandonment.
- No launch dates. No source here publishes one, so “never updated” is currently unreachable and every support life is a lower bound.
- Patch latency is unmeasurable for every product. 0 of 0 releases say they address security; 0 name a CVE id. Time from disclosure to fix cannot be computed from prose.
Getting it wrong
We will be. When it happens, the correction is published rather than quietly edited — a site that silently rewrites its own record has no standing to complain about vendors doing the same. See the correction log.