AI on the Factory Floor: Edge Inference and Machine Identity

Manufacturing is where AI meets machines that cost money when they stop. The IFR counted 542,000 industrial robots installed in 2024 and an operational stock of about 4.66 million, with China alone installing 295,000. Around them sit cameras, PLCs, sensors and gateways, all increasingly expected to run or feed AI models for inspection, predictive maintenance, scheduling and guidance.

Two requirements shape everything that follows: inference on the factory floor must keep working without the cloud, and every device that takes part must be able to prove what it is.

Place inference by consequence

Not every factory AI workload belongs at the edge. Place each by what happens if it is slow or unavailable:

The takeaway: anything that can stop the line runs on site and keeps running when the wide-area link fails. Everything else can be placed by cost.

Machine identity is the foundation

A factory network has hundreds or thousands of devices. Each one that sends data to an AI model, receives a model update or triggers an action needs an identity that cannot be copied. Industrial practice already points the way:

• IEEE 802.1AR defines secure device identifiers: a manufacturer-installed initial device identity (IDevID), stored so it cannot be modified, and locally significant identities issued by the operator, bound so they cannot be forged or moved to another device.
• IEC 62443 organises industrial security into zones and conduits with target security levels, and sets requirements for components, systems and the organisations that run them.

For AI, this means: a camera's images should be signed by the camera; a model running on a line server should be traceable to that server's hardware; and the identity should belong to the machine's chipset or secure element, not to a swappable accelerator card or a readable serial number that any software can copy.

Model integrity on the shop floor

A model on a production line is software that makes quality decisions. Treat it like firmware:

• Pin by hash. The line server loads only model files whose hashes match a signed list.
• Signed updates. New models and new runtime versions arrive as signed releases, installed by the operator at a chosen time.
• Refuse unsafe formats. Reject model formats that can execute code on load.
• Record what ran. Each decision records the model hash and the machine that made it, so a defect escape can be traced.

The regulatory clock

In the EU, NIS2 lists several manufacturing sectors (among them medical devices, computers and electronics, electrical equipment, machinery and vehicles) as critical sectors subject to cybersecurity risk-management and incident-reporting duties. The Cyber Resilience Act adds duties for manufacturers of products with digital elements: its reporting obligations for actively exploited vulnerabilities and severe incidents have applied since 11 September 2026, with most other requirements from 11 December 2027.

Outside the EU, IEC 62443 is widely referenced in industrial procurement, and APAC manufacturing hubs increasingly require it from suppliers. For AI on the factory floor, the practical consequence is the same everywhere: device identity, signed updates and traceable decisions are becoming conditions of sale, not extras.

A reference design

1. Devices (cameras, sensors, controllers) with secure elements or TPMs, signing what they emit.
2. A line or site server running inspection and maintenance models locally, with verified model files, its own hardware identity and no hard dependency on the wide-area link.
3. A site network segmented into zones per IEC 62443, with conduits for AI traffic.
4. Escalation to regional capacity for heavier models, by exception, under the site's data policy.
5. A decision record per inference: device, model hash, server identity, time, result.

What this means for manufacturers and hardware makers

• Specify hardware roots of trust in every new device purchase.
• Run line-critical AI on site and test it with the uplink cut.
• Bring model files under the same change control as PLC code.
• For hardware makers: an IDevID or equivalent attestable identity, plus a signed update path, is becoming a requirement for selling into EU factories.

Where Tenzro fits

Tenzro is an open network where machines of every size, from edge devices to data-centre GPUs, serve AI under one identity model. For manufacturing, built today:

• Hardware-anchored machine identity. A machine is admitted only if a person or organisation delegated it or an attestable hardware root anchors it. Graded identity sources include TPM 2.0 endorsement keys and IDevID, Secure Enclave, SEV-SNP and TDX identifiers and secure elements such as ATECC608 and SE050. GPU serials are never identity sources, and readable serials cannot anchor a machine on their own.
• Keys sealed to hardware. A machine's signing key is sealed to its hardware root; a host that cannot seal is refused rather than falling back to a key file.
• Verified models and signed releases. Model files are checked against pinned hashes and verified manifests before loading; pickle-based files are refused at ingest. Node releases are signed, and an operator's node verifies size and hashes before installing at a time the operator chooses.
• Private networks and private nodes. An operator can bootstrap a self-contained network for a site or join an existing private network, and can run nodes that are never announced.
• Signed sensor readings. A device's signature over a reading's digest and time can be checked against its registered key.

The edge build for small devices forwards model calls to providers; on-site inference runs on the standard or GPU provider build on a site server. A small-GPU edge variant is planned. The network is live in preview. See tenzro.com.