Development, begins together.
Banner alanı
IFM Sensor

🔐 Closing Backdoors in the Production Line for IoT Security!

Ahmet Ö.

Corporate
  • EMS Engineer
  • art_570_9c6d9b3f5ba5994a377e6c89bc8ee752.jpg

    🕵️‍♂️ An Unexpected Discovery​


    A few years ago, during a routine pre-screening of new IoT hardware, our team found a potential bug in the new devices. But even more interestingly, we noticed that one of these devices was sending traffic to an unexpected destination. This raised suspicions that the device might be malicious, and we immediately launched an investigation. If this device had infiltrated our infrastructure, serious financial and reputational losses could have occurred.

    🏭 Supply Chain Weaknesses​


    So how did this happen? Based on our previous experiences, we suspected that the supplier might have had disruptions in their supply chain, manufacturing and assembly processes, or testing and quality assurance stages. Such situations are increasingly common due to the complexity of the international IT equipment supply chain. Even if a device passes all internal controls, it may carry a technological risk, intentional or accidental, that no one is aware of.

    🚧 Why Are Security Specifications Overlooked?​


    Design specifications state intentions, and security is often a goal for most IT equipment manufacturers, including IoT and OT device manufacturers. However, producing a product often requires balancing time-to-market and profit margins. This can lead to security requirements being overlooked, adjusted, or sometimes maliciously altered.

    • Debugging Interfaces: There can be simple vulnerabilities, such as debugging interfaces remaining active after a product has shipped.
    • Component Changes: Sometimes a manufacturer or sub-assembler might use a lower-cost chipset that is compatible with the original specification but has undesirable features not accounted for in the original security design.
    • Default Credentials: Default or hardcoded credentials are one of the most common weaknesses in IoT and other networked devices.
    • Software Vulnerabilities: Even if manufacturers conduct extensive security testing, there may be existing or future vulnerabilities by the time the device reaches the customer.

    Most of these problems do not stem from malice; rather, they are the result of the constraints mentioned above and the efforts of well-intentioned people trying to solve a problem.

    😈 Why Are Backdoors Valuable to Adversaries?​


    Adversaries understood long ago that discovering or inserting a backdoor before a device ships is easier than attacking it in the field. In 2025, Reuters reported that US energy officials found undocumented cellular radios in some Chinese-made solar inverters. This type of vulnerability scales with every unit shipped.

    Manufacturing has been the most targeted sector for years. An open path to a programmable logic controller (PLC) can disrupt or override safety features on a production line. This results in downtime, additional costs, and regulatory penalties.

    ⚖️ Regulators Are Aware of the Situation​


    While IEC 62443 specifies security requirements for industrial components throughout their development lifecycle, the EU Cyber Resilience Act mandates that products containing digital elements be placed on the market without known exploitable vulnerabilities. A shipped backdoor, whether accidental or not, is now a compliance violation.

    🛠️ The Solution Starts on the Production Line​


    Solving this problem doesn't start with a new network control. It starts with viewing your manufacturing partner as part of your attack surface and security processes.

    • Add Security Requirements to the Contract: Write the credential scheme, debugging interfaces, services that need to be disabled, and firmware components that need to be tested and approved as a testable requirement in the manufacturing contract.
    • Verify the Work: Request a software bill of materials with every firmware delivery and a signed build manifest that you can verify against what was shipped.

    IEC 62443-4-1 already defines what a secure development lifecycle looks like on the supplier side; you are simply demanding compliance.
     
    Back
    Top