Preventing IoT Device Cloning IoT device cloning occurs when attackers capture real devices, extract cryptographic keys or identifiers, and use them to build duplicates that appear legitimate to the cloud service. Once deployed, these clones can manipulate data, spy on communications, or act as backdoors for larger attacks. The risk applies to all IoT protocols and solutions, since any system that relies on devices providing their credentials to the cloud service can be compromised if those secrets are stolen. Figure 1: Hacker extracts secrets from the device and inserts them into a Python program MQTT, however, is particularly vulnerable. As a one-to-many communication protocol, a single cloned device can subscribe broadly, especially if brokers lack strict access-control lists (ACLs) or allow wildcard (#) subscriptions, granting attackers visibility into the entire message flow. Securing private keys and other sensitive information is, therefore, critical to preventing device cloning. Why Device Cloning is So Dangerous: Using MQTT as an Example Let’s take a simple example: Device A connects to the MQTT broker with valid credentials. The broker is permissive; no ACLs, and wildcard subscriptions are allowed. An attacker clones Device X and uses the same credentials to connect to the online MQTT broker. Now the cloned device can: Subscribe to # and capture every message in the system to learn how it works. Publish commands as if it were the original device. Undermine the entire deployment, since the broker can’t distinguish between the genuine device and the clone. This is not just theoretical. It’s been demonstrated multiple times in production systems, and it usually stems from one thing: credentials that can be extracted and copied. A TPM Stops Device Cloning A TPM (Trusted Platform Module) stops device cloning by protecting cryptographic keys in tamper-resistant hardware, ensuring they can’t be copied to another device. The catch is that TPMs require specialized hardware and a carefully designed chain of trust, which can be very costly and complex to implement. A softTPM, like the one built into Xedge, solves this by delivering the same core protection in software. It anchors keys and trust directly in the device runtime, eliminating the need for extra chips or complex hardware integration. The result: strong anti-cloning security that’s far easier to understand and deploy. Xedge introduces a softTPM, which behaves like a TPM Module but runs within the Barracuda App Server environment. The key point is this: The private key never leaves the softTPM boundary . . All TLS handshakes, certificate requests, and signing operations happen inside the TPM context. Copying firmware or filesystem data does not expose the key. So even if someone clones your code, the clone cannot authenticate to the broker, because the key material doesn’t exist outside of the original device’s TPM. softTPM Workflow The softTPM ensures that every device has a unique, unclonable identity by tightly controlling how cryptographic material is generated and used. The following workflow shows how devices are securely bootstrapped, bound to certificates, and authenticated to the broker. Device bootstrapping On startup, the softTPM deterministically derives a device-unique pre-master key. This key is regenerated to the same value at each boot, but it never leaves the TPM boundary. From this pre-master key, the softTPM derives the cryptographic material needed for secure operations. A Certificate Signing Request (CSR) is generated and sent to the cloud or provisioning service, binding the device to a unique, unclonable identity. Certificate binding The cloud or provisioning service issues an X.509 certificate tied to the TPM-protected private key. This certificate is stored on the device, while the private key remains locked inside the softTPM and is never exposed. Note that only the private key requires protection; the certificate generated by the provisioning service using the CSR can be stored unprotected on the device. Broker authentication When connecting to the MQTT broker, the device authenticates using mutual TLS (mTLS). The broker verifies the device’s certificate against its trusted Certificate Authority (CA). If an attacker clones the firmware, the clone fails the TLS handshake because the private key cannot be reproduced, preventing successful authentication. Conclusion If your system relies on passwords, tokens, or file-stored keys, cloning is inevitable once an attacker gains physical access to the device. Likewise, relying only on firmware signing or secure boot ensures integrity but not identity. A cloned device can still present valid credentials to the cloud. By anchoring private keys inside a hardware TPM or a softTPM, you prevent key extraction. This means even if the firmware or filesystem is copied, the clone cannot authenticate because the original key material never exists outside the TPM boundary. In this workflow, MQTT was used as an example because it is especially vulnerable to cloning attacks when brokers lack strict access controls and allow wildcard subscriptions. However, device cloning poses a serious risk across all IoT protocols. The decisive factor is not the protocol itself, but whether or not your system protects its cryptographic keys from being copied. For more information on why MQTT is particularly vulnerable to cloning attacks, see the tutorial How Hackers Can Easily Penetrate Your MQTT Solution. This tutorial includes a practical MQTT penetration program you can run directly in your browser.