When ZBT routers, sold globally as white-label products, were found to contain manufacturer-implanted backdoors, it exposed a critical gap in hardware procurement controls. These routers reached organizations through resellers and rebranding, bypassing the scrutiny typically applied to named-vendor relationships.
This checklist is for procurement-security teams assessing network hardware and embedded systems. It focuses on routers, switches, IoT gateways, and similar components where firmware integrity is crucial.
Prerequisites
Before starting the assessment, ensure you have:
- Technical specification sheet from the vendor, detailing the chipset manufacturer, firmware build process, and update mechanism.
- Bill of materials or component sourcing disclosure, if available.
- Security contact at the vendor who can respond to technical queries within 48 hours.
- Sample device for testing if the contract value exceeds your organization's threshold for physical evaluation (typically $50K+ annually or critical-infrastructure classification).
If the vendor can't provide a security contact or refuses to share basic architecture details, consider this a red flag.
Checklist Items
1. Verify the Actual Manufacturer
Action: Confirm if your vendor manufactures the hardware or resells white-labeled products.
Requirement reference: ISO 27036-3 requires identification of all parties in the supply chain with access to the product.
Good looks like: The vendor provides a written statement identifying the manufacturer by legal entity name, confirms whether the product is manufactured under the vendor's brand or white-labeled, and discloses any ODM relationships.
2. Request Firmware Build and Signing Documentation
Action: Ask for documentation on the firmware build process, code signing procedures, and cryptographic key management.
Requirement reference: SR 23-4 emphasizes understanding how third parties maintain system security.
Good looks like: You receive a process document showing who has access to sign firmware releases, how signing keys are protected, whether builds are reproducible, and how unauthorized firmware modifications are detected.
3. Identify All Network Services Enabled by Default
Action: Obtain a complete list of listening ports, enabled protocols, and default credentials in the factory configuration.
Requirement reference: This aligns with Secure by Design principles requiring vendors to ship products in a secure default state.
Good looks like: The vendor provides a port matrix showing every service, its purpose, whether it can be disabled, and whether it requires authentication. Services like Telnet, FTP, or undocumented management interfaces should not appear in this list.
4. Confirm Update and Patch Delivery Mechanism
Action: Document how firmware updates are delivered, authenticated, and installed.
Requirement reference: EBA Guidelines on Sound Management of Third-Party Risk require understanding how vendors maintain security over time.
Good looks like: Updates are delivered over HTTPS with certificate pinning, signed with keys separate from diagnostic/support access, and include release notes describing security fixes. The vendor commits to a maximum response time for critical vulnerabilities.
5. Test for Undocumented Access Methods
Action: If you have a sample device, scan for open ports, analyze firmware for hardcoded credentials, and monitor outbound connections during initial setup.
Requirement reference: This is fundamental due diligence for critical infrastructure components.
Good looks like: Your testing reveals no listening services beyond those documented in item 3, no hardcoded passwords in extracted firmware, and no outbound connections to undocumented IP addresses. Consider engaging a hardware security firm for critical deployments.
6. Review the Vendor's Component Sourcing Controls
Action: Ask how the vendor validates the integrity of chips, modules, and other components they integrate.
Requirement reference: This addresses Cyber Supply Chain Risk Management concerns, particularly for products assembled from global component sources.
Good looks like: The vendor describes their supplier vetting process, confirms they source components from authorized distributors, and can trace the provenance of security-critical components like crypto processors or TPMs.
7. Establish Incident Notification Obligations
Action: Add contract language requiring the vendor to notify you within 24 hours if they discover backdoors, unauthorized access, or compromise of signing keys.
Requirement reference: SR 23-4 requires notification timelines for incidents affecting the service provided to your organization.
Good looks like: Your contract includes a Notification Timeline clause specifying that discovery of firmware integrity issues, unauthorized code, or key compromise triggers immediate notification, with a written incident report within 72 hours.
8. Secure Right to Audit Firmware and Build Processes
Action: Include a Right to Right to Audit covering firmware source code review and build environment inspection.
Requirement reference: EBA Outsourcing Guidelines require audit rights proportional to the criticality of the arrangement.
Good looks like: Your contract permits annual audits of the firmware build process, with the right to engage a third-party security firm at your expense. For white-labeled products, the Right to Audit should extend to the actual manufacturer, not just your reseller.
Common Mistakes
Treating all hardware vendors as equivalent to SaaS providers. Network hardware requires physical supply chain controls and firmware integrity checks that don't apply to cloud services. Don't use your standard SaaS questionnaire.
Accepting "proprietary security" as justification for non-disclosure. Refusing to explain the firmware signing process or update mechanism isn't protecting trade secrets; it's hiding the absence of controls.
Skipping technical testing for "trusted" brands. White-labeling means the brand on the box may not match the entity that wrote the firmware. The ZBT case shows that manufacturer-level compromise bypasses brand reputation.
Focusing only on the reseller in white-label arrangements. Your contract is with the reseller, but your risk is with the manufacturer. Audit rights and notification obligations must flow through to the entity that controls the firmware.
Next Steps
After completing this checklist:
- Tier the finding. If you can't verify firmware integrity controls (items 2, 3, and 5), classify this as a critical gap requiring executive escalation.
- Update your Criticality Classification criteria. Network infrastructure that routes production traffic or connects to sensitive segments should automatically trigger the full checklist, regardless of contract value.
- Review existing hardware deployments. If you've deployed routers, switches, or IoT devices in the past two years without completing items 2-6, add them to your remediation backlog.
The ZBT disclosure isn't an isolated supply chain failure. It's a signal that hardware procurement controls haven't kept pace with supply chain threats. This checklist won't catch every implant, but it will force vendors to demonstrate basic firmware integrity controls or disqualify themselves before they reach your network.
