A few years ago, during a routine prelaunch review of new connected IoT hardware, our team scanned a batch of brand new, latest model hardware and found a potential bug, which was not uncommon, but also noticed something else.
When they added the devices to the network after setting up the proper configuration, they saw something unexpected. As many are aware, security folks tend to be a bit suspicious (of a lot of things!), ask a lot of questions, and are on the lookout for things that could pose a threat to the infrastructure.
In the case of our newly connected network devices, we noticed traffic beaconing from one of the devices to a destination that was not expected. The team immediately began an investigation and found packets of data leaving the device to destinations that were never entered into any configuration or were part of the specifications received from the vendor.
The chatty device looked identical to the other units but clearly was doing something we suspected was malicious. Had this device been introduced within our infrastructure, unnoticed, there could have been financial and reputational impacts down the road.
How did this happen? Based on previous experience, we suspected potential breakdowns in the vendor’s supply chain, product manufacturing and assembly, or testing and quality assurance processes.
Running prelaunch security assessments on connected hardware and working with equipment manufacturers, we have seen this situation grow because of the sheer complexity of the international supply chain for IT equipment.
A device can clear every internal milestone and still ship carrying a technology risk nobody knows about, whether accidental or intentional. A network controller could arrive on a pallet, get plugged into the line, pass every check, and run as expected for months. Then a backdoor could suddenly wake up based on signaling by a threat actor.
The flaw could have been there from Day One, introduced somewhere in the supply chain. The unfortunate result in many cases is that once a flawed and potentially malicious device is on the line and running, there is a good chance nobody assesses or monitors its activity again unless it sits behind a robust security stack.
Why the security spec may not survive the build
A design specification describes intent, and security is usually something most makers of any IT equipment, including IoT and OT device manufacturers, intend. However, producing a product usually involves trade-offs and optimization of time-to-market demands and profit margins.
This coupled with diversified supply chains and component assembly can cause security requirements to be missed, adjusted, or sometimes altered with malicious intent to the supply chain.
Security flaws can be as simple as a debug interface remaining enabled after a product ships. Debug mode makes testing and remediation go faster, but sometimes it doesn’t get disabled. Sometimes a manufacturer or downstream component assembler may swap in a lower cost chipset compatible with the original specification but with unintended features not included in the original security design.
Another issue is dealing with default or hardcoded credentials. Nobody likes these, but they are out there out of necessity and remain one of the most common weaknesses in IoT, OT and other network connected devices.
Sometimes an implementation guide or user manual includes options for addressing this situation, such as wiring in an identity platform, or just changing the passwords to something that is hopefully too hard to guess. And sometimes, unfortunately, there are identities and passwords on the device that aren’t documented in the spec at all.
Security flaws and vulnerabilities in software also are a challenge with IoT and OT devices. Even if a manufacturer does extensive security testing of their software, there still could be vulnerabilities, either current or future, present in the device by the time it is deployed by the customer.
Most of these product implementation choices and issues do not get introduced out of malice. They are there because of the constraints mentioned above by well-intended people solving a problem.
Security flaws can be as simple as a debug interface remaining enabled after a product ships. Debug mode makes testing and remediation go faster, but sometimes it doesn’t get disabled.
Not many people confirm that the device coming off the line still matches the secure design developed in the lab and documented in the specification. Partners just assume the spec was complete. The brand assumes the partner followed the rules because it’s probably in their agreement. The hardware ships on two assumptions that were never validated.
Why shipped backdoors are worth so much to adversaries
Adversaries worked this out a while ago. Discovering or planting a backdoor before a device ships is easier than attacking it in the field.
In 2025, Reuters reported that U.S. energy officials had found undocumented cellular radios inside some Chinese made solar inverters, components that appeared in no product specification or documentation. Intent was never established, and that is the problem. You cannot judge intent on hardware that has not gone through assessment during its lifecycle. An undetected firmware flaw scales across every unit that ships.
Manufacturing has been the most targeted industry for years, drawing 27.7% of all the incidents IBM X-Force observed. An exposed path into a programable logic controller could interrupt or override safety features in a production line.
Impacts arrive as downtime and remediation activities, additional costs, and the potential for regulatory penalties. One major event could negate whatever the cheaper build saved, and the cost compounds when the devices are already deployed and every one of them has to be remediated in place.
The exposure also scales with outsourcing. The electronics manufacturing services market reached $648 billion in 2025, with Asia Pacific holding nearly 45% of it, and industrial hardware rides the same offshoring as everything else, sent overseas in a cost reduction that looks great on paper.
Regulators are aware. IEC 62443 sets security requirements for industrial components across the development lifecycle, and the EU Cyber Resilience Act requires products with digital elements to reach market without known exploitable vulnerabilities. A shipped backdoor, whether it’s accidental or not, is now a compliance failure.
Closing the gap starts on the build floor
Fixing this does not start with another network control. It starts with treating your manufacturing partner as part of your attack surface and security processes.
First, write the security requirements and specifications into the manufacturing contract as a testable requirement. Name the credential scheme, the debug interfaces, the services that have to ship disabled, and the firmware components that must be tested and approved. Ensure software and firmware can be updated or upgraded.
Regulators are aware. Government security requirements for industrial components now mean that a shipped backdoor, whether it’s accidental or not, is a compliance failure.
IEC 62443-4-1 already defines what a secure development lifecycle looks like on the supplier side, you are simply requiring conformance.
Second, check the work. Require a software bill of materials with each firmware delivery and a signed build manifest you can verify against what ships. That turns it into a yes or no answer and should catch a swapped component before it leaves.
Then bring in a third party to attack the device the way a real adversary would, while the units are still on the floor. Internal QA confirms the device does what it is supposed to do, but they now need to check what the device does that nobody was expecting. This is exactly where an exposed management path or a hardcoded credential could hide.
Podcast: How AI is altering the landscape of manufacturing cybersecurity
Third, push identity down to the individual unit. A unique credential provisioned into the hardware at build time and bound to that serial number is the difference between one compromised device and a compromised fleet.
IEEE 802.1AR has described how to do this for many years now, and firmware signing anchored in a hardware root of trust, per NIST SP 800-193, is what keeps that identity meaningful after the first update.
Fourth, make sure someone looks at the device again. Put the asset in inventory with a named and accountable owner, place it in a segmented zone with defined conduits per IEC 62443-3-2, and make sure unexplained egress from a controller generates an alert.
Fifth, where possible, place these devices behind a mature and evolving security stack with real-time visibility and ongoing assessment by the security team.
The EU Cyber Resilience Act’s vulnerability reporting obligation takes effect in September 2026 and applies to products already on the market, with the full requirements, including no known exploitable vulnerabilities, secured by default configuration, and machine readable SBOMs, being required by December 2027.
The controller on the pallet either had that discipline behind it or it didn’t. Find out now, on the floor, but don’t wait until later.
