I recently worked with an IoT project where we discussed device provenance during a security review. The question was simple: can you prove which firmware was installed on a specific device during manufacturing? The answer was no. Firmware builds existed in CI systems, device identities lived in spreadsheets, and assembly logs sat in a database that any admin could modify. The cryptographic chain that should connect these stages did not exist.
This is not unusual. Large scale IoT deployments depend on manufacturing processes that are rarely verifiable after devices leave the factory. Firmware provenance, key ownership, and assembly responsibility are documented in internal systems that cannot be independently audited. When incidents occur, operators lack cryptographic evidence that links a deployed device to its manufacturing history.
Industry guidance from cloud providers and standards bodies consistently identifies manufacturing time identity provisioning and firmware signing as the foundation of IoT security. What is missing in many implementations is an immutable, verifiable record that ties these steps together.
What Manufacturing Guidance Actually Requires
AWS and Microsoft both document that secure IoT manufacturing requires three concrete controls:
- Unique device identity established at manufacturing time
- Firmware integrity verification using cryptographic signatures
- Controlled ownership of signing keys and certificate authorities
AWS explicitly states that device identity and key material should be provisioned before deployment and tracked throughout the device lifecycle. The whitepaper, published November 2022 and now marked as historical reference, remains the canonical guidance for X.509 certificate provisioning in manufacturing environments.
Source: AWS Device Manufacturing and Provisioning Whitepaper
Microsoft similarly requires X.509 based device identity and signed firmware for production grade IoT deployments. Their documentation emphasizes certificate chains and hardware security modules for protecting device private keys.
Source: Azure IoT Hub X.509 authentication documentation
NIST provides complementary guidance through SP 800-213 (IoT Device Cybersecurity Guidance) and SP 800-183 (Networks of Things), which address device pedigree as a core trustworthiness concern. SP 800-183 specifically identifies that sensors and aggregators from unknown pedigree with possible nefarious intent represent a fundamental risk category.
Source: NIST SP 800-213: IoT Device Cybersecurity Guidance
None of these documents claim that identity alone is sufficient. They assume the existence of manufacturing records that can be trusted later. In practice, those records are often mutable databases or spreadsheets.
The Gap Between Guidance and Reality
In real manufacturing environments, multiple parties are involved. Firmware is built by one system, devices are assembled by another, and provisioning may happen in a different environment entirely. Each step may be logged, but logs are rarely cryptographically linked.
This creates common failure modes:
- Firmware hashes cannot be reliably traced back to a specific build
- Assembly stations cannot prove which firmware they installed
- Audits depend on trust rather than verification
These are not theoretical risks. The XZ Utils backdoor discovered in early 2024 demonstrated how malicious code can be inserted into widely used open source components, affecting Linux-based IoT software across thousands of potential deployments. Manufacturing supply chains face the same attack surface: compromised build tools, tampered firmware images, and malicious code embedded before devices reach customers.
NIST's Executive Order 14028 guidance on software supply chain security identifies these attack patterns explicitly. The guidance requires organizations to verify the provenance of software components and maintain evidence of secure development practices.
Source: NIST Executive Order 14028: Improving the Nation's Cybersecurity
The cerbtk Proof of Concept
The novatechflow cerbtk repository implements a minimal device registry backed by an append only ledger. It is not a blockchain product and does not claim decentralization. Its purpose is to demonstrate how manufacturing events can be recorded in a verifiable way.
sha256 + Ed25519
device_id + fw_hash
POST /register
GET /validate
Source: novatechflow cerbtk GitHub repository
The registry accepts signed device registration payloads that include:
- Device identifier
- Firmware hash and build metadata
- Public key material
- Timestamp and signing algorithm
Each payload is verified before being appended to the ledger. The ledger exposes validation and head verification endpoints that allow auditors to detect tampering.
CI logs only
Mutable DB
No provenance
Signed hash
Append-only
Verify registry
How This Maps to Manufacturing Workflows
The cerbtk model aligns directly with documented manufacturing best practices:
- Firmware signing keys remain centralized and controlled
- Assembly stations act as signing clients, not authorities
- Every device registration is cryptographically verifiable
This approach does not replace PKI or cloud provisioning services. It complements them by preserving manufacturing evidence in a form that can be independently validated.
A registry of this kind can be anchored to external systems, exported for audits, or integrated into downstream provisioning pipelines without relying on proprietary formats.
Why Append Only Matters
Append only logs are widely used in security critical systems because they allow detection of deletion and modification. Certificate transparency logs, which have recorded over 2.5 billion certificates since 2013, use the same principle. Software supply chain attestations like SLSA (Supply chain Levels for Software Artifacts) also depend on append only evidence stores.
Source: Certificate Transparency documentation
Applying this model to IoT manufacturing creates a durable link between physical devices, firmware artifacts, and signing authorities. The operational benefit is not lower compute cost but faster audits, simpler partner integration, and immutable evidence when disputes arise.
Conclusion
Secure IoT manufacturing requires more than identity provisioning. It requires evidence that survives organizational boundaries and time. The cerbtk proof of concept demonstrates how signed manufacturing events and append only registries can close a documented gap between security guidance and operational reality.
This applies established cryptographic practices to a stage of the IoT lifecycle that remains under protected. The same principles that secure certificate issuance and software builds can secure device manufacturing, if organizations choose to implement them.
If you need help with distributed systems, backend engineering, or data platforms, check my Services.