This article is the second part of our exploration into where security truly begins and how it must be sustained. While many systems still rely heavily on encryption as the core of their security model, the most dangerous attacks often occur after initial authentication—through identity masquerading and spoofing inside the system. That is why the essence of modern security lies not in a “one-time check,” but in a device’s ability to continuously prove that it is genuine at every moment.
In this post, we take a closer look at why the starting point of continuous trust must be a Hardware Root of Trust (HRoT), and why only a PUF-based HRoT can fully meet the requirements for an uncompromisable foundation of device identity.
| When Trust Backfires: The Dragon King, the Terrapin… and the Rabbit Who Outsmarted Them All
Following our previous analogy with The Wolf and the Seven Little Goats, let’s turn to a well-known Korean folktale this time—The Story of the Rabbit and the Dragon King.
In this classic tale, the Dragon King is told that he needs a rabbit’s liver to cure his illness. Believing the rabbit would obediently sacrifice itself, he orders his loyal terrapin to bring the rabbit to the underwater palace. To him, confirming that the rabbit was “genuine” at the moment of entry seemed more than enough.
But the clever rabbit manages to earn just enough trust to survive the situation.
๐ฐ “Your Majesty, I left my liver on land. I must return to retrieve it.”
The Dragon King and the terrapin continue trusting the rabbit simply because the rabbit initially appeared cooperative and genuine.
And what happened next is obvious.
Once the rabbit returned to land, it had no intention of ever going back to the Dragon Palace. The Dragon King was deceived because he relied entirely on one-time confirmed trust—and never questioned it again.
This is precisely where the critical flaw of today’s IoT security surfaces:
the dangerous assumption that once trust is established, it will continue unchallenged.
In the previous episode, we emphasized that the root cause of modern breaches is not the limitation of encryption technologies, but device identity spoofing—malicious actors impersonating trusted devices after the initial credential check.
๐๐ป Read the previous episode: “Beyond Encryption: Why "Trust" Is Becoming the Core of Modern Security "
So the key question is this:
“If a device is verified as genuine once, is it truly safe afterward?”
Just like the lesson from The Story of the Rabbit and the Dragon King,
the answer is — No.
| The Danger of a “One-Time Authentication” Security Model
Most IoT systems still operate under a familiar pattern:
| Initial enrollment/authentication → Trust granted → Long-term use without re-verification
Once a device is registered as legitimate, it is trusted for an extended period without question.
And this “indefinite extension of trust” becomes the perfect opening for attackers.
The most vulnerable moment in any security architecture is when an attacker successfully looks like an insider.
Attackers rarely try to break in by acting “abnormally.”
Instead, their goal is to make every malicious action appear perfectly legitimate.
Credential theft allows an attacker to behave exactly like a trusted device.
Software hacking lets compromised code operate as if it were genuine.
Firmware tampering hides malicious routines behind what looks like normal behavior.
Cloned device creation enables counterfeit hardware to enter the system while masquerading as an authentic product.
In every case, the intent is the same:
to blend in as a normal, trusted device.
In other words, attackers aren’t trying to “break down the door.”
Instead, they choose the strategy of looking exactly like the homeowner.
| Initial authentication is a necessary condition — but never a sufficient one.
Encryption hides the content of communication.
Initial authentication verifies who the other party is.
But here’s the real problem:
“There is no guarantee that the identity verified at the initial moment will remain valid afterward.”
Once a device slips inside the system, everything operates under the assumption that the device is trustworthy.
It’s the same as:
a hotel that treats anyone as a valid guest simply because they checked in once,
a building where anyone with an old access card can walk right in,
a company where possession of an employee badge provides unrestricted access to internal servers.
Trust should never be a one-time event.
It must be continuously validated.
| Why HRoT Is the Foundation of Continuous Trust
An HRoT is not merely a tool for initial authentication.
A device equipped with a Hardware Root of Trust can independently perform three critical functions:
Guarantee its own unique identity, blocking cloning and spoofing attempts.
Verify that it has not been tampered with before booting, encrypting, or authenticating—enabling secure boot and integrity checks.
Maintain its identity consistently during operation, making continuous trust possible.
In other words, an HRoT is not simply a mechanism that starts security.
It is the starting point of all device identity, the foundation of continuous trust, and the anchor on which all other trust decisions depend.
The most dangerous attacks are not the ones pounding on the door from the outside.
They are the ones that have already made their way inside.
A security model based on one-time authentication creates opportunities for attackers.
A model built on continuous identity validation, however, leaves no place for attackers to hide behind “false trust.”
If encryption protects data, continuous identity proof is what protects the system.
It is the essence of security.
This leads us to the core question of Zero-Trust Devices:
“Is this device — and its software — still genuine right now?”
To answer that question at every moment, trust must not originate from the initial authentication event.
It must originate from within the device itself.
That is the role of the HRoT we have repeatedly emphasized.
But this raises an even more fundamental question:
“What if the very identity anchor of the HRoT could be forged?”
Any stored identity — a stored ID, stored key, or memory-based credential — can eventually be extracted, duplicated, or tampered with.
For an HRoT to be truly trustworthy, its identity cannot be stored; it must be generated.
And it must be impossible to clone.
Only a PUF-based (Physically Unclonable Function) HRoT satisfies all of these conditions.
It is the only structure capable of delivering continuous, uncompromisable identity proof all the way through.
While other approaches focus on protecting stored secrets,
a PUF stores no secrets that can be stolen.
It begins from something fundamentally different:
not a key that must be hidden,
but a unique, unreplicable physical identity — an existence that is the key.
In the next episode, we will dive deeper into what a PUF is and why it matters.
๐ Before moving on to the next episode, explore the fundamentals of PUF here.
| When Trust Backfires: The Dragon King, the Terrapin… and the Rabbit Who Outsmarted Them All
Following our previous analogy with The Wolf and the Seven Little Goats, let’s turn to a well-known Korean folktale this time—The Story of the Rabbit and the Dragon King.
In this classic tale, the Dragon King is told that he needs a rabbit’s liver to cure his illness. Believing the rabbit would obediently sacrifice itself, he orders his loyal terrapin to bring the rabbit to the underwater palace. To him, confirming that the rabbit was “genuine” at the moment of entry seemed more than enough.
But the clever rabbit manages to earn just enough trust to survive the situation.
๐ฐ “Your Majesty, I left my liver on land. I must return to retrieve it.”
The Dragon King and the terrapin continue trusting the rabbit simply because the rabbit initially appeared cooperative and genuine.
And what happened next is obvious.
Once the rabbit returned to land, it had no intention of ever going back to the Dragon Palace. The Dragon King was deceived because he relied entirely on one-time confirmed trust—and never questioned it again.
This is precisely where the critical flaw of today’s IoT security surfaces:
the dangerous assumption that once trust is established, it will continue unchallenged.
In the previous episode, we emphasized that the root cause of modern breaches is not the limitation of encryption technologies, but device identity spoofing—malicious actors impersonating trusted devices after the initial credential check.
๐๐ป Read the previous episode: “Beyond Encryption: Why "Trust" Is Becoming the Core of Modern Security "
So the key question is this:
“If a device is verified as genuine once, is it truly safe afterward?”
Just like the lesson from The Story of the Rabbit and the Dragon King,
the answer is — No.
| The Danger of a “One-Time Authentication” Security Model
Most IoT systems still operate under a familiar pattern:
| Initial enrollment/authentication → Trust granted → Long-term use without re-verification
Once a device is registered as legitimate, it is trusted for an extended period without question.
And this “indefinite extension of trust” becomes the perfect opening for attackers.
The most vulnerable moment in any security architecture is when an attacker successfully looks like an insider.
Attackers rarely try to break in by acting “abnormally.”
Instead, their goal is to make every malicious action appear perfectly legitimate.
Credential theft allows an attacker to behave exactly like a trusted device.
Software hacking lets compromised code operate as if it were genuine.
Firmware tampering hides malicious routines behind what looks like normal behavior.
Cloned device creation enables counterfeit hardware to enter the system while masquerading as an authentic product.
In every case, the intent is the same:
to blend in as a normal, trusted device.
In other words, attackers aren’t trying to “break down the door.”
Instead, they choose the strategy of looking exactly like the homeowner.
| Initial authentication is a necessary condition — but never a sufficient one.
Encryption hides the content of communication.
Initial authentication verifies who the other party is.
But here’s the real problem:
“There is no guarantee that the identity verified at the initial moment will remain valid afterward.”
Once a device slips inside the system, everything operates under the assumption that the device is trustworthy.
It’s the same as:
a hotel that treats anyone as a valid guest simply because they checked in once,
a building where anyone with an old access card can walk right in,
a company where possession of an employee badge provides unrestricted access to internal servers.
Trust should never be a one-time event.
It must be continuously validated.
| Why HRoT Is the Foundation of Continuous Trust
An HRoT is not merely a tool for initial authentication.
A device equipped with a Hardware Root of Trust can independently perform three critical functions:
Guarantee its own unique identity, blocking cloning and spoofing attempts.
Verify that it has not been tampered with before booting, encrypting, or authenticating—enabling secure boot and integrity checks.
Maintain its identity consistently during operation, making continuous trust possible.
In other words, an HRoT is not simply a mechanism that starts security.
It is the starting point of all device identity, the foundation of continuous trust, and the anchor on which all other trust decisions depend.
The most dangerous attacks are not the ones pounding on the door from the outside.
They are the ones that have already made their way inside.
A security model based on one-time authentication creates opportunities for attackers.
A model built on continuous identity validation, however, leaves no place for attackers to hide behind “false trust.”
If encryption protects data, continuous identity proof is what protects the system.
It is the essence of security.
This leads us to the core question of Zero-Trust Devices:
“Is this device — and its software — still genuine right now?”
To answer that question at every moment, trust must not originate from the initial authentication event.
It must originate from within the device itself.
That is the role of the HRoT we have repeatedly emphasized.
But this raises an even more fundamental question:
“What if the very identity anchor of the HRoT could be forged?”
Any stored identity — a stored ID, stored key, or memory-based credential — can eventually be extracted, duplicated, or tampered with.
For an HRoT to be truly trustworthy, its identity cannot be stored; it must be generated.
And it must be impossible to clone.
Only a PUF-based (Physically Unclonable Function) HRoT satisfies all of these conditions.
It is the only structure capable of delivering continuous, uncompromisable identity proof all the way through.
While other approaches focus on protecting stored secrets,
a PUF stores no secrets that can be stolen.
It begins from something fundamentally different:
not a key that must be hidden,
but a unique, unreplicable physical identity — an existence that is the key.
In the next episode, we will dive deeper into what a PUF is and why it matters.
๐ Before moving on to the next episode, explore the fundamentals of PUF here.