How unclonable identity creates real trust within a system
"So where does this technology actually get used?"
At some point while learning about PUF, this question surfaces almost inevitably. The concept makes sense, the importance is clear — but how it connects to actual products and systems still feels out of reach.
I felt the same way. I had worked through what VIA PUF™ does, how it differs from SRAM PUF and RO PUF, and why it matters. But when it came to the question of how it actually operates inside a real device, I found myself back at square one.
Answering that question requires understanding one thing first. VIA PUF™ is not, by itself, a complete security solution. More precisely, VIA PUF™ is the foundational layer that makes HRoT (Hardware Root of Trust) possible — and the actual security functions operate on top of that HRoT. When VIA PUF™ physically anchors a chip's identity, every security function above it — authentication, encryption, integrity verification — gains a trustworthy starting point.
Put another way: everything we have covered so far — why identity-based attacks have become a central security challenge, why initial authentication alone is not enough, how PUF differs from stored keys — all of it leads to a single question. How does that unclonable identity actually generate trust within a real system? That is what this installment is about.
What HRoT Actually Does — What "Root of Trust" Really Means
When I first encountered the term Hardware Root of Trust, I imagined something imposing — a dedicated security module inside a device, acting as a shield against every conceivable threat. The reality is more precise than that. HRoT is not a shield. It is a reference point.
From the moment a device powers on to the moment it exchanges data, the system is continuously making trust judgments. Has this firmware been tampered with? Is this communication partner who it claims to be? Is the code currently running the code that was approved? For these judgments to hold, there needs to be a single, stable reference against which they are made. HRoT is that reference — the point that must not move if everything built on top of it is to be trusted.
This is where VIA PUF™ enters. As earlier installments covered, when identity depends on stored information, a system loses its ability to distinguish between two devices if that information is replicated. VIA PUF™ takes a different approach: rather than storing identity, it generates identity from the physical characteristics of the chip's internal VIA structures. The physical properties determined when the chip is manufactured cannot be read from the outside or reproduced identically elsewhere.
The significance of this is not simply that it is "more secure." When HRoT's reference point is anchored in physical structure, every security function above it acquires meaning. Judgments can only be trusted when the basis for those judgments cannot be moved. VIA PUF™-based HRoT places that basis in physics, not software.
VIA PUF™-Based HRoT in Practice — How It Works Across a Device's Lifecycle
The clearest way to understand what VIA PUF™-based HRoT actually does is to follow a device across its lifecycle. From manufacture to field operation, HRoT creates trust differently at each stage — but always from the same physical foundation.
At the manufacturing stage, identity is established in the process of making the chip itself. VIA PUF™ reads the physical variations that naturally occur in a chip's internal VIA structures during fabrication and generates a unique value from them. This value is not injected from outside — it emerges from the chip's own physical structure. As a result, millions of chips built from the same design each carry a distinct identity. The fingerprint exists before the device leaves the factory.
At the boot stage, Secure Boot uses this identity as its reference point. When a device powers on, the first thing it does is confirm that the firmware it is about to run matches what was originally approved. The basis for that confirmation is the unique key generated by VIA PUF™ — not a stored key, but one derived from physical structure each time it is needed. If firmware has been tampered with, this verification step catches it before execution begins.
At the operational stage, a device must continuously prove its identity as it communicates with external systems. HRoT provides the foundation for device certificate issuance and mutual authentication. A certificate signed with a key derived from VIA PUF™ cannot be reproduced without the physical chip it came from. When a device's identity is grounded in physical structure, producing a replica that carries the same valid credentials becomes structurally impossible.
Taken together, these three stages reveal that VIA PUF™-based HRoT is not simply a security component — it is a consistent foundation running through the entire life of a device. Identity established at manufacture, integrity verified at boot, and authentication sustained through operation all rest on the same physical base. This is what "Continuous Trust," introduced in ep.2, looks like when it is actually implemented.
The practical weight of this becomes clearer with a concrete example. Imagine tens of thousands of sensors connected across a network, and one of them replaced somewhere in the supply chain with a counterfeit. When identity relies on certificates or stored keys alone, replicating that information is enough to make the counterfeit indistinguishable to the system. With VIA PUF™-based HRoT, the physical structure that generates the key cannot be duplicated — so the counterfeit fails at the authentication stage, regardless of what credentials it carries.
So How Does This Connect to Real Products?
Understanding VIA PUF™-based HRoT as a concept is one thing. How it connects to actual systems can still feel abstract. That gap is understandable.
The core point is this: when the starting point of trust sits in hardware — in physical structure rather than software — every security function built above it operates on a more stable foundation. As the number of connected devices grows, as networks become more complex, as supply chains extend further, the significance of where that starting point sits becomes harder to ignore. When identity becomes uncertain at any one point in a connected system, the effect does not stay contained.
The Question That Remains
This series began by asking why security gets compromised. Identity-based attacks — where the question is not whether encryption is strong, but whether a device is genuinely what it claims to be — have moved to the center of the security challenge. The answer we have arrived at is that addressing this requires not stored keys but a physical foundation that cannot be replicated.
The difference between devices that have this foundation and those that do not may not be visible when only a handful of devices are involved. At thousands or tens of thousands of devices, the difference determines the trust level of the entire system.
For security architects and procurement decision-makers, the question is shifting — from "which encryption algorithm?" toward "where does trust begin?" And where trust begins is not a product decision. It is a design decision.
Read more
How unclonable identity creates real trust within a system
"So where does this technology actually get used?"
At some point while learning about PUF, this question surfaces almost inevitably. The concept makes sense, the importance is clear — but how it connects to actual products and systems still feels out of reach.
I felt the same way. I had worked through what VIA PUF™ does, how it differs from SRAM PUF and RO PUF, and why it matters. But when it came to the question of how it actually operates inside a real device, I found myself back at square one.
Answering that question requires understanding one thing first. VIA PUF™ is not, by itself, a complete security solution. More precisely, VIA PUF™ is the foundational layer that makes HRoT (Hardware Root of Trust) possible — and the actual security functions operate on top of that HRoT. When VIA PUF™ physically anchors a chip's identity, every security function above it — authentication, encryption, integrity verification — gains a trustworthy starting point.
Put another way: everything we have covered so far — why identity-based attacks have become a central security challenge, why initial authentication alone is not enough, how PUF differs from stored keys — all of it leads to a single question. How does that unclonable identity actually generate trust within a real system? That is what this installment is about.
What HRoT Actually Does — What "Root of Trust" Really Means
When I first encountered the term Hardware Root of Trust, I imagined something imposing — a dedicated security module inside a device, acting as a shield against every conceivable threat. The reality is more precise than that. HRoT is not a shield. It is a reference point.
From the moment a device powers on to the moment it exchanges data, the system is continuously making trust judgments. Has this firmware been tampered with? Is this communication partner who it claims to be? Is the code currently running the code that was approved? For these judgments to hold, there needs to be a single, stable reference against which they are made. HRoT is that reference — the point that must not move if everything built on top of it is to be trusted.
This is where VIA PUF™ enters. As earlier installments covered, when identity depends on stored information, a system loses its ability to distinguish between two devices if that information is replicated. VIA PUF™ takes a different approach: rather than storing identity, it generates identity from the physical characteristics of the chip's internal VIA structures. The physical properties determined when the chip is manufactured cannot be read from the outside or reproduced identically elsewhere.
The significance of this is not simply that it is "more secure." When HRoT's reference point is anchored in physical structure, every security function above it acquires meaning. Judgments can only be trusted when the basis for those judgments cannot be moved. VIA PUF™-based HRoT places that basis in physics, not software.
VIA PUF™-Based HRoT in Practice — How It Works Across a Device's Lifecycle
The clearest way to understand what VIA PUF™-based HRoT actually does is to follow a device across its lifecycle. From manufacture to field operation, HRoT creates trust differently at each stage — but always from the same physical foundation.
At the manufacturing stage, identity is established in the process of making the chip itself. VIA PUF™ reads the physical variations that naturally occur in a chip's internal VIA structures during fabrication and generates a unique value from them. This value is not injected from outside — it emerges from the chip's own physical structure. As a result, millions of chips built from the same design each carry a distinct identity. The fingerprint exists before the device leaves the factory.
At the boot stage, Secure Boot uses this identity as its reference point. When a device powers on, the first thing it does is confirm that the firmware it is about to run matches what was originally approved. The basis for that confirmation is the unique key generated by VIA PUF™ — not a stored key, but one derived from physical structure each time it is needed. If firmware has been tampered with, this verification step catches it before execution begins.
At the operational stage, a device must continuously prove its identity as it communicates with external systems. HRoT provides the foundation for device certificate issuance and mutual authentication. A certificate signed with a key derived from VIA PUF™ cannot be reproduced without the physical chip it came from. When a device's identity is grounded in physical structure, producing a replica that carries the same valid credentials becomes structurally impossible.
Taken together, these three stages reveal that VIA PUF™-based HRoT is not simply a security component — it is a consistent foundation running through the entire life of a device. Identity established at manufacture, integrity verified at boot, and authentication sustained through operation all rest on the same physical base. This is what "Continuous Trust," introduced in ep.2, looks like when it is actually implemented.
The practical weight of this becomes clearer with a concrete example. Imagine tens of thousands of sensors connected across a network, and one of them replaced somewhere in the supply chain with a counterfeit. When identity relies on certificates or stored keys alone, replicating that information is enough to make the counterfeit indistinguishable to the system. With VIA PUF™-based HRoT, the physical structure that generates the key cannot be duplicated — so the counterfeit fails at the authentication stage, regardless of what credentials it carries.
So How Does This Connect to Real Products?
Understanding VIA PUF™-based HRoT as a concept is one thing. How it connects to actual systems can still feel abstract. That gap is understandable.
The core point is this: when the starting point of trust sits in hardware — in physical structure rather than software — every security function built above it operates on a more stable foundation. As the number of connected devices grows, as networks become more complex, as supply chains extend further, the significance of where that starting point sits becomes harder to ignore. When identity becomes uncertain at any one point in a connected system, the effect does not stay contained.
The Question That Remains
This series began by asking why security gets compromised. Identity-based attacks — where the question is not whether encryption is strong, but whether a device is genuinely what it claims to be — have moved to the center of the security challenge. The answer we have arrived at is that addressing this requires not stored keys but a physical foundation that cannot be replicated.
The difference between devices that have this foundation and those that do not may not be visible when only a handful of devices are involved. At thousands or tens of thousands of devices, the difference determines the trust level of the entire system.
For security architects and procurement decision-makers, the question is shifting — from "which encryption algorithm?" toward "where does trust begin?" And where trust begins is not a product decision. It is a design decision.
Read more