Protecting Model IP on Deployed Inference Hardware 2026 — Weight Encryption, Secure Boot & Anti-Cloning

When an AI product leaves the factory, the model leaves with it. Weights, architecture, calibration tables and the inference logic behind years of training and domain data now sit inside a box the customer physically owns, powers up, and can open with a screwdriver. A competitor buying one unit and dumping its storage is the cheapest route to a cloned product — cheaper than building the model, and usually cheaper than reverse-engineering the board.

This is a different problem from data confidentiality. Confidential computing protects the customer’s data from the infrastructure operator; here the asset is the model itself, and the adversary is the party holding your hardware. The two overlap in the silicon they use, but the design target is inverted: you are protecting yourself from the person you sold the device to.

The Threat Model You Have to Write Down

Name the adversary before choosing hardware, because each arrives with different access.

• The service technician. The customer’s own maintenance staff hold the console password by design. Anything readable by root on a running device is, in practice, readable by the customer.
• The competitor who buys a unit. The cheapest attack. One purchase, one storage dump, and your inference logic is on their bench.
• The contract manufacturer or reseller. Has the image, the build scripts and often the signing keys unless you split custody.
• The insider. Build-system access rather than physical access — usually the shortest path to the weights.
• The lab-equipped attacker. Side-channel and fault-injection work. Lowest probability, highest effort, and only worth defending against for high-value models.

Five attacks follow from that list, roughly in order of effort: dumping the flash or NVMe; using a live JTAG or UART debug port; scraping RAM on a running device; patching the licence branch out of the binary; and side-channel analysis. Only the first three are defeated by hardware you can buy, which is why they get the budget.

It is worth being blunt about why file obfuscation alone fails. Any wrapper must turn ciphertext back into plaintext weights before the GPU can multiply against them. If the model runs, its plaintext exists in RAM for part of every inference — the attacker only has to be present at the right moment. The controls that hold are the ones that keep the key out of reach, not the ones that hide the ciphertext. That is the difference between deterrence and a security property.

The Hardware Controls That Actually Work

Five layers, each with a different trust anchor:

• Boot integrity. Silicon ROM anchors a chain into a signed bootloader, signed kernel and signed rootfs — Jetson Secure Boot with OP-TEE on Arm, Intel Boot Guard and TXD or AMD SEV on x86. The chain is worthless while the debug port stays live, so fusing off JTAG and UART in production OTP is the highest-value single line in the BOM.
• Key custody. A discrete secure element (ATECC608 class) or a TPM 2.0 holds the model key and releases it only to a measured OS state. Binding the release to PCR values means a tampered boot simply never receives the key.
• Storage at rest. A TCG Opal 2.0 self-encrypting drive, or LUKS/dm-crypt with the key sealed to the TPM. This defeats the drive pulled from the box and read on a bench — the attack that needs no skill at all.
• Runtime protection. GPU confidential-compute mode keeps weights and activations encrypted in HBM so a memory scrape returns ciphertext, and encrypted PCIe DMA closes the host-to-GPU leg.
• Provisioning. Per-device keys injected at assembly, and models delivered attestation-gated: the device proves its identity and measured state before receiving an envelope-encrypted artefact. Weights never ship inside the OS image at all, which removes the single easiest dump target.

Four Protection Postures, Priced

Most teams should pick a posture deliberately rather than defaulting to whichever feature the SoC happens to expose.

Choose by the ratio of model value to unit volume. A $5,000 inspection appliance running a model that cost $2M to build justifies posture D. A $200 sensor node whose model anyone could retrain does not. The common mistake is buying posture B for a genuinely valuable model: signed boot and an encrypted store with an online key still leave the weights in plaintext memory at every inference, which is exactly where the attacker was going to look.

What Each Platform Actually Offers

Two procurement realities matter more than the matrix. First, capability is per-SKU, not per-brand: secure boot and TrustZone are available on Jetson Orin and Thor, but debug fusing and per-device key injection are contract-manufacturing steps that must be specified in writing, not assumed. Second, the standards now carry dates. NIST SP 800-193 covers firmware resiliency, IEC 62443-4-2 sets component-level security requirements, FIPS 140-3 governs the crypto module itself, and the EU Cyber Resilience Act’s Article 14 vulnerability-reporting duty went live on 11 September 2026, with Annex I conformity obligations following on 11 December 2027.

Writing It Into the BOM and the Contract

• Fuse the debug ports on production parts, and confirm the OTP state in writing
• Specify TPM 2.0 or a discrete secure element on every unit, and state where the key lives
• Demand an Opal 2.0 or LUKS path for the model store, with the key sealed to measured state
• Require attestation-gated model delivery; never ship weights inside the OS image
• Define who holds the signing keys after the contract manufacturer finishes the build
• Ask for the runtime memory-protection claim — if it is not confidential-compute mode, say so
• Get secure-boot and fusing evidence per SKU, not per brand
• Map the design to NIST SP 800-193 and IEC 62443-4-2 now, ahead of the CRA deadlines

QSCompute supplies the hardware side of secure inference deployment — Jetson Orin and Thor modules with secure boot, TPM-equipped fanless industrial PCs, confidential-compute-capable GPUs, and TCG Opal industrial NVMe storage for encrypted model stores.