Skip to content

A channel from factory to brand, and a record of everything that passes through it.

VexRoute maps your products to the firmware they run and the factories behind them. When a vulnerability hits, the factory answers once and every affected brand gets that answer. When nothing is happening, the record keeps working for you.
Get startedBook a demo
The firmware-family modelSix SKUs map to three firmware families, which are supplied by two ODMs. One answer per family covers every SKU that runs it.CAM-210CAM-220CAM-310SEN-04SEN-05HUB-01IPC-T31 v4ZB-Lite 2Linux-GW 5ODM AShenzhenODM BDongguanYour SKUsFirmware families

Two modes, one system

Incidents are where the CRA's clock is loudest. But most of the value builds up quietly, in the months between them.

Incident mode

When a CVE hits a chipset, SDK or platform

  • One structured question to each affected factory, in Chinese and English
  • The factory answers once per firmware family with a VEX status
  • Every linked brand sees its affected SKUs and firmware versions
  • The CRA clock starts and stays visible
  • A pre-filled ENISA packet for the 24-hour and 72-hour reports

Year-round mode

Every other day of the year

  • A live map of SKUs, firmware families, suppliers and ODMs
  • Every question and answer kept with timestamps
  • VEX statements and SBOM-linked status per family
  • Firmware updates, supplier changes and support periods recorded
  • Evidence ready for retailers, tenders, auditors and Notified Bodies

More on year-round compliance

Built around firmware families, not SKUs

A firmware family is a codebase a factory maintains and ships across many products. It's the unit that's actually vulnerable, so it's the unit VexRoute asks about.

You link each SKU to the family it runs. The factory confirms which families it maintains and which versions are current. From then on, one answer per family reaches every SKU and every brand that depends on it, without anyone retyping it.

It also makes the hidden structure of your catalogue visible: which products share code, which factory carries the most of your range, and where a single chipset advisory would hit hardest.

An incident, step by step

From the moment an advisory appears to the moment your notification is ready.

  1. Step 1: The question goes out

    A brand, a consultant or VexRoute raises a vulnerability against the firmware families it may touch. Each factory gets one bilingual request, not twenty.

  2. Step 2: The factory answers once

    R&D answers per family: not affected, affected, fixed or under investigation, with a justification, versions and mitigation in Chinese or English.

  3. Step 3: Every brand is covered

    The answer is routed to every linked brand and mapped to its own SKUs. Brands never see each other. The CRA clock is visible from awareness onward.

  4. Step 4: You report with confidence

    Your ENISA packet arrives pre-filled. You review, add what only you know and submit through the single reporting platform. Everything is logged.

The ENISA packet, pre-filled

VexRoute doesn't file for you. You're the manufacturer, and the report is yours. What it does is take the blank page away.

Early warning draft

Due in 17 h 42 min

Product and affected SKUs
CAM-210, CAM-220 (IPC-T31 v4.2)
Firmware versions affected
4.2.0 to 4.2.6
Supplier statement
Affected. Fixed in 4.2.7. ODM A, answered 08:14 CST
Mitigation available to users
Update to 4.2.7; disable remote access until updated
Member states where the product is available
You confirm
Suspected malicious or unlawful act
You confirm

Illustrative draft. Field names simplified.

The parts that depend on the factory, such as which products and versions are affected, what the supplier says, and what users can do, are filled from the factory's answer, with the source and timestamp kept alongside.

The parts only you can decide stay with you: where the product is sold, whether you suspect malicious activity, and anything your consultant advises you to add.

The same draft grows into the 72-hour notification as the factory updates its answer, and into the final report once the fix ships.

The evidence trail

Every link, question, answer and update is stored against the SKU, firmware family and supplier it concerns. It's the record auditors, Notified Bodies and procurement teams ask for, built as a side effect of doing the work.
Illustrative evidence trail: each SKU linked to a firmware family, its ODM, and the latest VEX status
SKUFirmware familySupplierVEX statusLatest answer
CAM-210Indoor cameraIPC-T31 v4.2ODM A, ShenzhenFixedFirmware 4.2.7 shipped
CAM-220Doorbell cameraIPC-T31 v4.2ODM A, ShenzhenFixedSame family, same answer
SEN-04Door sensorZB-Lite 2.xODM B, DongguanNot affectedChipset not used
PLG-11Smart plugWB3S-Plug 1.9ODM C, ZhongshanUnder investigationAnswer due in 6 h
HUB-01Home hubLinux-GW 5.1ODM A, ShenzhenAffectedMitigation published
Illustrative data. Two cameras share one firmware family, so one factory answer covers both.

VEX and SBOM, without the jargon

A VEX statement says whether a product is affected by a specific vulnerability, and why. An SBOM lists what the firmware is made of. Together they turn 'we think we're fine' into something you can show.
Not affected
The vulnerable component isn't compiled into this firmware family.
Affected
The vulnerable code is present and reachable. Mitigation advice attached.
Fixed
Resolved in firmware 4.2.7, released to brands on the date recorded.
Under investigation
R&D is checking. The factory commits to an update time.

Factories answer with one of the four standard VEX statuses and a short justification. That keeps answers comparable across suppliers and exportable to the formats your customers and tools expect.

Where an SBOM exists, VexRoute links it to the firmware family, so a status can point to the exact component it concerns. Where one doesn't exist yet, you can still start, and add it later. SBOMs become mandatory under the CRA from December 2027.

Security and data handling

A tool that sits between factories and brands has to earn both sides' trust. These are the rules we build to.
Brands never see each other
The factory answers once per firmware family, but each brand only sees its own SKUs, questions and evidence. Customer lists stay private.
Factories share answers, not source
No source code is needed. Factories answer about families they already supply, and choose what supporting detail to attach.
Least access by default
Access is scoped per organisation and per role, so purchasing, compliance and factory R&D each see what they need and nothing more.
Every change is logged
Answers are versioned, never overwritten. Who said what, and when, is part of the record. That's the point of an evidence trail.
Encryption and hosting
Encryption in transit and at rest is a baseline, not an upgrade. Hosting, data-residency and security documentation are available on request for your procurement and security review.

Integrations

Connect VexRoute to the formats and tools your teams already use. Integrations are rolling out in stages; ask us which are available for your setup.
  • Coming soon

    SBOM import

    CycloneDX and SPDX files linked to firmware families, so statuses tie to components.

  • Coming soon

    VEX export

    Export answers as CSAF VEX or OpenVEX documents for your own tooling and customers.

  • Coming soon

    Reporting packet export

    Structured export of the early-warning and notification fields, ready to transfer into the single reporting platform.

  • Coming soon

    Advisory intake

    Watch chipset vendor and platform advisories, and suggest which firmware families to ask about.

  • Coming soon

    Factory-side messaging

    Notifications through WeCom, Feishu, DingTalk and email, so R&D sees questions where they already work.

  • Coming soon

    Ticketing

    Push incidents and answers into Jira or ServiceNow on the brand side.

Need something else connected? Tell us what you use.

See it against your own catalogue.

Map your SKUs, connect your factories and have a working CRA response channel in place. Talk to us about your range and we'll show you VexRoute on your own products.

Get startedBook a demo

Or write to menachem@vexroute.com.