Devices that join a network at first boot, with hardware identity

A device leaves the factory with an identity, whether or not anyone designed one. It may be a serial number in fuses, a MAC address, a certificate in flash or a key in a secure element. That identity decides what the device can do in the field: whether it can be trusted with a workload, paid for its work, updated safely and handed to a new owner without risk. As AI moves onto gateways, cameras, robots and small computers, the question is no longer only whether a device is secure. It is whether a device can take part in an economy of machines from the moment it first powers on.

This article is for manufacturers designing that first moment.

Not every identifier can anchor a machine

Hardware identifiers are not equal. It helps to grade them in three tiers.

Model identifiers name a design, not a unit. A CPU's family, model and stepping, or an Arm core's MIDR_EL1 register, read the same on every chip of that design. A fingerprint built from them is identical across a whole product line.

Fused identifiers are unique to each unit but readable. These include processor serials, SoC unique IDs in OTP fuses, board serials and SMBIOS UUIDs. They tell you which machine claims to be talking. But any software running on the device can read them, and anyone who has read one can claim it from anywhere.

Attestable identifiers are unique per-unit secrets that can prove possession without revealing themselves. Examples include a TPM 2.0 endorsement key, a secure enclave, a secure element such as an ATECC608 or SE050, a confidential-computing processor key, or a DICE-derived identity.

Only the third tier can anchor a machine that no person or organisation has vouched for. If a network accepts a fused serial as identity, its anchor rule offers no real protection.

Two corollaries are worth designing for. First, do not use an accelerator's identifier as the machine's identity. GPUs and NPU cards are swapped, resold and partitioned, so the identity would follow the card rather than the machine. Second, never publish a fused serial in the clear. It is a stable cross-service tracker. If it must be used at all, carry only a hash of it.

Layered identity for constrained silicon

Not every product can afford a discrete TPM. The Trusted Computing Group's Device Identifier Composition Engine (DICE) targets this case. Boot ROM reads a unique device secret from immutable storage, locks it away, and derives an identity for each firmware stage from the measurement of the next. As Android's DICE documentation explains, changing any firmware image changes the identity of that stage and every stage after it. That gives a small microcontroller both an identity and a verifiable record of what it booted.

The design point for manufacturers is that the root secret should never be reachable by mutable software. Everything else can be derived from it.

Seal the key, never write it down

A device that holds its own signing key should seal it to the hardware root, not store it in a file. A key in a file can be copied by a backup, a stolen storage card, a container escape or a misconfigured permission. Whoever copies it becomes the machine, with no human to notice. A sealed key exists on disk only as ciphertext under the hardware's storage hierarchy.

There is a firm rule here worth adopting: a device that cannot seal should be refused, not quietly downgraded to a plaintext key. The devices allowed to speak for themselves should be exactly those able to protect the key they speak with.

First boot is an onboarding protocol

Manufacturers rarely know where a device will be deployed. The FIDO Alliance's Device Onboard specification addresses this with late binding: the owner chooses the management platform late in the device's life, and the device finds it through a rendezvous service on first connection. One manufactured device can onboard to many platforms without being modified.

Joining an open AI network is the same problem with more at stake, because the device will be paid for work and trusted with requests. A good first-boot flow does five things in order:

1. Proves the hardware root with an attestable key, not a readable serial.
2. Binds an owner. Either a person or organisation delegates the device and stays accountable for it, or the hardware root itself stands in because nobody delegated it.
3. Creates a wallet whose keys are generated and held by the same hardware.
4. Profiles the hardware so the network routes to it only the work it can actually do.
5. Refuses roles it cannot serve rather than accepting and failing later.

Ownership transfer needs equal care. A device anchored by an accountable owner should move only on that owner's authority. Possession of the hardware should not be enough to take a machine that someone is accountable for, since that is a compromise, not a sale.

Regulation is converging on the same basics

Rules for connected products are tightening across regions. In the EU, the Cyber Resilience Act entered into force on 10 December 2024. Its reporting obligations apply from 11 September 2026 and its main obligations from 11 December 2027, with security by design and vulnerability handling across the product's life. The UK's product security regime has applied since 29 April 2024 and bans universal default passwords, among other requirements. In Japan, IPA's JC-STAR labelling scheme launched in March 2025, and METI has announced mutual recognition with Singapore's Cybersecurity Labelling Scheme at the baseline level from 1 June 2026.

None of these laws requires a particular identity architecture. But unique, hardware-protected credentials, measured boot and a clean ownership story make each of them easier to meet, and the same design serves all of these markets.

What this means for hardware manufacturers

Put an attestable root on every SKU that will do paid or trusted work, whether that is a TPM, a secure element or a DICE-capable boot ROM. Expose it through standard interfaces so software can seal keys and produce attestations without vendor-specific code. Treat first boot as a protocol, not a provisioning script, and leave the choice of network to the owner. Devices designed this way can earn in the field, not just run.

Where Tenzro fits

Tenzro is an open network where machines from small edge devices to GPU servers sell AI work. It is live in preview, and governance decides the steps to testnet and mainnet. What is built for device makers:

• The anchor rule. A machine identity is admitted only if a human or institution delegated it, or if an attestable hardware root stands in its place. Identifier sources are graded as attestable, fused or model, and only attestable sources can anchor an undelegated machine. No GPU identifier is accepted as an identity source.
• Broad hardware coverage. Attestable sources include TPM 2.0 EK and IDevID, Apple Secure Enclave, AMD SEV-SNP, Intel SGX and TDX, Qualcomm QFPROM and StrongBox, ATECC608, NXP SE050, ESP32 digital-signature peripherals and others. Only a SHA-256 digest of a fused value is ever carried.
• Sealed keys. Signing keys are sealed to the hardware root, and a host that cannot seal is refused.
• Device binding. A phone or laptop counts as hardware-bound only when an attestation shows its key is held in a TEE or secure element and the credential cannot sync off the device. Credentials eligible for cloud backup are disqualified.
• Join flow. One command provisions identity, a hardware-rooted wallet and a hardware profile. The light build for small devices refuses roles that run models at startup.
• Small footprint. On an aarch64 test host, the light build was 86.8 MB stripped (62.2 MB size-optimised) and held 130 to 210 MiB resident while idle. A Raspberry Pi, which has no TPM, can keep its identity key in another machine's TPM, at the cost of a round trip per signature.

Not yet built: 32-bit ARM and RISC-V builds, and the planned edge role in which devices host agent orchestration and small local models.