Artificial Intelligence (AI) is rapidly becoming embedded in everyday life, powering applications across surveillance systems, smart cities, industrial automation, autonomous robots, connected vehicles, healthcare devices and intelligent assistants.

As AI moves from centralized cloud environments to distributed edge devices, models, data, and decision-making capabilities are increasingly deployed closer to where actions occur. This widespread adoption creates tremendous opportunities for real-time intelligence, but it also significantly expands the attack surface, making trust, integrity, and security fundamental requirements across the entire AI lifecycle — from edge to cloud.

A trained AI model is a company’s intellectual property. As it is updated over the air, replicated across distributed nodes, and orchestrated from the cloud, AI model protection has to hold across the entire workflow, not just at the edge where the data is captured. That means proving three things continuously:

●        that the device is genuine,

●        that the model running on it is unmodified and authentic, and

●        that the data feeding it has not been tampered with.

Why is Edge AI Security so challenging?

Securing Edge AI is fundamentally more challenging than traditional embedded systems because AI shifts high-value assets such as trained models, inference logic, and decision-making capabilities from protected cloud environments to distributed edge devices.

As AI models have become deployable intellectual property, they become attractive targets for theft, tampering, and reverse engineering. At the same time, sensitive data is increasingly processed locally on devices, raising privacy, data leakage, and compliance risks.

Unlike centrally managed cloud infrastructures, Edge AI deployments often consist of large, geographically distributed fleets of devices operating outside direct organizational control, making secured updates, remote attestation, device integrity verification, and policy enforcement significantly more difficult. As a result, security must extend beyond traditional device protection and provide an integrated trust architecture that simultaneously protects the device and the AI models that drive its decisions.

The result is that AI model integrity has to be enforced at three layers at once, and a gap at any one of them undermines the other two:

●        Device trust — is this a genuine device, or a cloned one presenting a copied identity?

●        Model trust — is the model that is about to execute the one the manufacturer signed, or a modified or substituted one?

●        Data trust — did the sensor input and the training data actually originate where they claim to have originated?

Each stage of the workflow — data capture at the edge, aggregation, training, model packaging and distribution, inference, and cloud orchestration — is a trust boundary. Every unverified node in that chain is a place where model IP can leak, training data can be poisoned, or a compromised device can be admitted into a distributed deployment.

The Hardware Root of Trust that enables verifiable AI Model Protection

The approach that closes the gap is to move the keys — and the operations that use them — into a discrete, tamper-resistant security controller. Keys are generated and used inside that boundary. Encryption and decryption happen inside it. The host processor asks the security controller for a result; for this operation it does not need to see the key that produced the result.

Applied to an AI model, that gives a verifiable sequence rather than an assumed one. The model ships in encrypted form. Before it executes, the host computes a cryptographic hash of the model image and asks the security controller to verify it against a stored signature. Only if integrity and authenticity checks are OK, the controller unlocks the decryption key. The model is decrypted into memory and inference starts. If verification fails, the key is not unlocked, so the model is not decrypted, and execution is blocked. Trust becomes something the system proves and is verifiable, not something it assumes.

On platforms running a full operating system, the same principle extends upward through measured boot and device attestation: each stage of the boot chain is measured into the security controller before the next stage runs, producing signed evidence of the platform state that a remote service can verify before it admits the device or releases a model to it. That is what carries device identity from the edge into the cloud — and what allows a distributed or federated deployment to admit only nodes whose state it can check.

How Infineon enables it  

Infineon implements this approach with two hardware roots of trust that address complementary parts of the workflow. Which one fits — a secure element for edge AI, or a TPM for edge AI — is determined by the host architecture and the security requirement, not by a general ranking of one against the other.

OPTIGA™ Trust M is a turnkey security controller certified to PSA Certified Level 3. It anchors device identity, stores keys in tamper-resistant non-volatile memory, and performs signing and decryption inside its own isolated boundary — which is what makes it suitable as a Secure Element (SE) for edge AI where the model itself is the asset being protected. It connects over I²C with a shielded, encrypted connection, occupies a 3 × 3 mm USON-10 package, and is specified to work with any MCU or MPU, so it can be added to an existing design without changing the host processor.

Cryptographic support covers ECC on NIST curves up to P-521 and Brainpool r1 up to 512, RSA up to 2048, AES keys up to 256 bit, and HMAC up to SHA-512. Certificates and key pairs can be pre-provisioned at an Infineon facility, so a device arrives on the production line already carrying a unique identity.

OPTIGA™ Trust M product category page

OPTIGA™ TPMs provide a hardware-based root of trust that helps secure AI devices from the edge to the cloud. They protect cryptographic keys, verify platform integrity with measured boot and attestation, safeguard AI models and devices, and enable secured, authenticated communication with cloud services. By establishing end-to-end trust, OPTIGA™ TPMs help organizations deploy AI systems with stronger security, compliance, and resilience against threats.

OPTIGA™ TPM SLB 9672 (SPI) and SLB 9673 (I²C) are ready-to-use Trusted Platform Modules compliant with the TCG TPM 2.0 Library Specification revision 1.59, carrying Common Criteria EAL4+ and FIPS 140-2 Level 2 certification, with 51 kB of extended non-volatile memory.

They provide measured boot and attestation, so AI workloads run only on a platform whose state has been verified against a known-good baseline, and they extend that identity outward: OPTIGA™ TPM and OPTIGA™ Trust M support automatic device onboarding to AWS IoT Greengrass and Azure IoT Edge, which is what makes edge-to-cloud device identity cryptographically verifiable rather than asserted. In distributed and federated deployments, the same attestation evidence is what allows an orchestrator to admit only trusted nodes. Firmware updates are protected by a post-quantum XMSS signature scheme, and firmware recovery follows the NIST SP 800-193 platform firmware resiliency guidelines.

OPTIGA™ TPM product category page

OPTIGA™ Trust M is a turnkey security controller certified to PSA Certified Level 3. It anchors device identity, stores keys in tamper-resistant non-volatile memory, and performs signing and decryption inside its own isolated boundary — which is what makes it suitable as a Secure Element (SE) for edge AI where the model itself is the asset being protected. It connects over I²C with a shielded, encrypted connection, occupies a 3 × 3 mm USON-10 package, and is specified to work with any MCU or MPU, so it can be added to an existing design without changing the host processor.

Cryptographic support covers ECC on NIST curves up to P-521 and Brainpool r1 up to 512, RSA up to 2048, AES keys up to 256 bit, and HMAC up to SHA-512. Certificates and key pairs can be pre-provisioned at an Infineon facility, so a device arrives on the production line already carrying a unique identity.

OPTIGA™ Trust M product category page

OPTIGA™ TPMs provide a hardware-based root of trust that helps secure AI devices from the edge to the cloud. They protect cryptographic keys, verify platform integrity with measured boot and attestation, safeguard AI models and devices, and enable secured, authenticated communication with cloud services. By establishing end-to-end trust, OPTIGA™ TPMs help organizations deploy AI systems with stronger security, compliance, and resilience against threats.

OPTIGA™ TPM SLB 9672 (SPI) and SLB 9673 (I²C) are ready-to-use Trusted Platform Modules compliant with the TCG TPM 2.0 Library Specification revision 1.59, carrying Common Criteria EAL4+ and FIPS 140-2 Level 2 certification, with 51 kB of extended non-volatile memory.

They provide measured boot and attestation, so AI workloads run only on a platform whose state has been verified against a known-good baseline, and they extend that identity outward: OPTIGA™ TPM and OPTIGA™ Trust M support automatic device onboarding to AWS IoT Greengrass and Azure IoT Edge, which is what makes edge-to-cloud device identity cryptographically verifiable rather than asserted. In distributed and federated deployments, the same attestation evidence is what allows an orchestrator to admit only trusted nodes. Firmware updates are protected by a post-quantum XMSS signature scheme, and firmware recovery follows the NIST SP 800-193 platform firmware resiliency guidelines.

OPTIGA™ TPM product category page

Quantified Benefit  

  Each device stores a unique AES 256-bit key inside OPTIGA™ Trust M, and that key secures the AI model encryption key. Encryption and decryption take place inside OPTIGA™ Trust M. Thereby, the manufacturer’s IP embedded in the model can stay protected even if the device is lost, decommissioned or physically disassembled.  

OPTIGA™ TPM SLB 9672 and OPTIGA™ TPM SLB 9673 carry Common Criteria EAL4+ and FIPS 140-2 Level 2. Where a software-only or virtualized root of trust offers no equivalent independently evaluated assurance level, these figures are the comparison an evaluator can check.

Where Edge AI Security matters most

Three application areas concentrate the risk: they combine high-value models, physical accessibility, and fleets that operate outside direct organizational control.

Computer vision and security surveillance

Security cameras, video analytics, smart city surveillance and video doorbells run inference on models that took significant investment to train, on hardware mounted in publicly accessible locations. The model is the product differentiator, and the device is within reach of anyone with a ladder.

Industrial Edge AI infrastructure

Industrial gateways, routers, switches, edge compute nodes and PLC controllers make decisions that move machinery. Here the integrity question outweighs the confidentiality one: a substituted model does not just leak IP, it changes what the equipment does. Long service lifetimes make cryptographic agility a design requirement rather than an afterthought.

Physical AI

Humanoids and robotics combine distributed training across fleets with autonomous action in shared human spaces. Every node that contributes to training and every node that acts on a deployed model has to be verifiable, which makes device attestation the gating mechanism for fleet participation.

Key security principles for design considerations 

1. Encryption at rest prevents unauthorized access to stored models

2. Attestation-based key provisioning allows keys to reach only verified devices

3. Platform integrity verification prevents compromised devices from deceiving cloud services

4. Mandatory access control restricts unauthorized model access

5. Kernel hardening reduces privilege escalation attack surface

6. Runtime protections minimize plaintext exposure during execution

7. Comprehensive monitoring enables threat detection and incident response

Organizations deploying AI models on edge should view this architecture as an essential security foundation rather than an optional feature.

The investment in implementing these controls protects against millions of dollars in potential intellectual property theft while establishing processes and infrastructure for future hardware-based security enhancements. By adopting this framework, organizations gain:

●        IP Protection: Multi-layered defenses against model theft and unauthorized access

●        Compliance Ready: Alignable with regulatory requirements and industry security standards

●        Future Ready: Architecture prepared for hardware confidential computing when available

●        Operational Resilience: Monitoring and response capabilities for incident handling

●        Risk Reduction: Quantifiable reduction in attack surface and privilege escalation vectors

The combination of cryptographic protection, platform integrity, access control, and runtime safeguards creates a security posture appropriate for high-value AI intellectual property on edge devices. Implementation requires coordination across cloud services, device configuration, and operational practices, but the result is a robust framework protecting critical AI assets.

FAQ

Can I add hardware-based AI model protection to an existing edge design?

Yes — hardware-based AI model protection can be added to an existing design without changing the host processor. OPTIGA™ Trust M is specified to work with any MCU or MPU and connects over a single I²C interface with a shielded, encrypted connection. It ships in a USON-10 package measuring 3 × 3 mm, so the board impact is one small component and one bus. In addition, multiple host software libraries are available for OPTIGA™ Trust M, including C libraries for bare-metal microcontrollers, libraries for Linux-based systems, and Python libraries. This enables straightforward integration across a wide range of MCU and MPU platforms and is a key reason why the solution remains processor independent. OPTIGA™ TPM SLB 9672 uses SPI and OPTIGA™ TPM SLB 9673 uses I²C, both in a UQFN-32 package, and integrate with standard Linux and Windows TPM software stacks. Because the security controller is discrete rather than integrated into the application processor, the host architecture and the AI runtime do not have to change.

A cryptographic key securely stored inside OPTIGA™ Trust M protects the AI model encryption key. Depending on the application, both symmetric and asymmetric cryptographic mechanisms can be used, while all cryptographic operations are executed within the protected boundary of OPTIGA™ Trust M. The device supports a broad range of algorithms, including AES-256, ECC on NIST curves up to P-521 and Brainpool r1 curves up to 512, RSA up to 2048, and HMAC up to SHA-512. The choice of algorithm and key size depends on the security architecture; however, the security architecture remains the same: cryptographic keys are used in the security controller’s isolated boundary and are therefore not exposed to the host processor, even during cryptographic operations.

OPTIGA™ Trust M helps to establish key security properties for edge AI deployments by protecting confidentiality, integrity and authenticity of the AI models. AI models can be stored in encrypted form at rest, keeping model architectures and parameters protected against unauthorized access or extraction. By validating a model’s hash and signature before use, the device verifies that the model originates from a trusted source and has not been modified or tampered with, for example replaced by a malicious version.

AI models are often several KB, MB in size. Secure Elements are optimized for secured key storage and cryptographic services, not for processing large amounts of application data. Therefore, typically the process of envelope encryption is used, which separates responsibilities. OPTIGA™ Trust M secures and manages cryptographic keys. The MCU performs bulk decryption using a data encryption key. With that concept, the solution scales easily to larger AI models without requiring changes to the Secure Element.

Device binding cryptographically links an AI model to a specific device during provisioning. During manufacturing or onboarding, the model encryption key is protected using a device-specific cryptographic identity stored inside OPTIGA™ Trust M. As a result, only the intended device can recover the key required to decrypt the model. Even if an attacker copies the encrypted model, application software, and storage content, the model remains unusable on other hardware because the necessary credentials are bound to the original device. This approach helps to prevent model cloning and protects valuable AI model IP.

Yes — hardware AI model protection is available across industrial temperature ranges. OPTIGA™ Trust M is offered in standard and extended temperature versions, with the extended range covering −40°C to +105°C and carries a 20-year lifetime rating for industrial automation and infrastructure applications. OPTIGA™ TPM SLB 9672 is likewise available with an extended range of −40°C to +105°C for industrial use cases. For edge AI deployed in outdoor surveillance, industrial gateways or building infrastructure, the security controller’s temperature and lifetime ratings should be matched to the enclosure specification, not to the ambience rating of the AI processor alone.

Use OPTIGA™ TPM when the design needs platform-level trust, operating-system-aware integration, secured boot measurement, device health attestation, or standards-based onboarding into cloud and IoT infrastructure. This is common for Linux- or Windows-based gateways, industrial edge computers, PLCs, routers, switches, and other connected systems that must prove both device identity and software state. OPTIGA™ TPM SLB 9672 and OPTIGA™ TPM SLB 9673 are ready-to-use TPM 2.0 security solutions with SPI or I²C interface options, Common Criteria EAL4+ and FIPS 140-2 Level 2 certifications, extended non-volatile memory, and support for stronger cryptographic algorithms. A Secure Element such as OPTIGA™ Trust M remains the fit for processor-independent key protection and model encryption-key handling, while OPTIGA™ TPM is the fit when the full platform state must be measured, attested, and trusted from edge to cloud.

OPTIGA™ TPM provides a hardware-based root of trust for platforms that need measured boot and remote attestation. During startup, each relevant boot stage and software component can be measured into the TPM’s platform configuration registers. A remote service can then verify signed attestation evidence before it admits the device, provisions secrets, or releases an AI model. For Edge AI, this means the cloud does not have to trust a device identity claim on its own; it can check whether the platform state matches a known good baseline before allowing the node to participate in inference, fleet orchestration, or federated workflows. OPTIGA™ TPM devices are based on TCG TPM 2.0 specifications and are designed to help identify and authenticate connected devices while protecting data integrity and confidentiality.