June 16, 2026
Your Network Has Millions of Identities. Most of Them Are Unmanaged.
Ask a security engineer how many user accounts their organization manages, and they’ll give you a number within minutes. Ask them how many…
Chithara Karunasekera
7 min read
Ask a security engineer how many user accounts their organization manages, and they'll give you a number within minutes. Ask them how many non-human identities are active on their network right now. Service accounts, API keys, IoT devices, containerized workloads, automated pipelines, and you'll get a pause. Maybe a guess. Rarely a confident answer.
That gap between what organizations know about their human identities and what they know about everything else is not a minor bookkeeping problem. It is one of the most consequential blind spots in enterprise security today, and it is getting wider every year.
The Number You Can't Answer
How many non-human identities are active on your network right now?
The numbers are striking. Research consistently shows that non-human identities now outnumber human ones by a ratio of anywhere between 10:1 and 45:1 in modern enterprise environments, and this ratio is accelerating. Every microservice deployment adds service accounts. Every cloud migration adds IAM roles and API tokens. Every IoT rollout adds device identities by the hundreds or thousands, each one holding credentials, each one capable of authenticating to something.
The deeper problem is not the volume, but the visibility. Most organizations have mature tooling for human identity governance, such as joiner/mover/leaver workflows, access reviews, MFA enforcement, and session monitoring. However, for non-human identities, the governance story is far thinner. No one cares to see if a service account still needs the access it was granted 18 months ago. No one reviews whether the IoT device that has been quietly publishing data to a broker is still behaving the way it did when it was provisioned.
This is not negligence. It is a structural gap.
What Identity of Things Actually Means
The term Identity of Things (IDoT) sounds like an extension of IoT, and in some way, it is. However, the conceptual transformation it represents is more significant than the name suggests.
In classical IAM, Identity is a human construct. A principal is a person who can be held accountable, respond to an authentication challenge, and make a judgment call when something looks suspicious. The entire architecture of identity management, from password policies to MFA to access reviews, is built around the assumption that there is always a human at the end of the chain.
IDoT deliberately breaks that assumption.
It asks: What does it mean to give a thing an identity?
Not a username tied to a device, but a genuine, managed, lifecycle-aware identity for the device itself that can be issued, governed, rotated, revoked, and continuously validated, independent of any human user.
Things as principals
In terms of IDoT, when a device holds an identity, it becomes a principal in its own right. It can authenticate. It can be authorized. It can be held to a behavioral standard. And critically, it can be untrusted, not because a human decided to revoke its access, but because the system determined that its behavior no longer matches what that identity is expected to do.
This is a meaningful distinction from simply tagging a device with a certificate and calling it authenticated.
A certificate answers one question:
"Is this the device it claims to be at this moment?"
IDoT asks a harder question:
"Is this device still behaving like itself, and should it still be trusted to do what it's currently doing?"
The scope of what qualifies
IDoT covers a broader surface than most assumptions. It is not just physical IoT sensors and actuators. It encloses:
- Edge computing nodes running autonomous workloads
- Drones and autonomous vehicles operating with minimal human oversight
- Industrial control systems in manufacturing and critical infrastructure
- Medical devices operating in clinical environments
- Connected vehicles communicating with infrastructure
- Any software agent or service acting autonomously on behalf of a system
"Autonomy" is what all these have in common. They act, authenticate, and make decisions without a human in the loop for every interaction. That autonomy is exactly what makes their identity management both critical and uniquely difficult.
Why Traditional IAM Wasn't Built for This
The assumptions that break when your identity is a temperature sensor
Traditional IAM rests on a set of assumptions so deeply embedded in its architecture that they are rarely stated explicitly. The problem is that every one of them breaks when the principal is a device.
Assumption 1: The principal can respond to a challenge
Every major authentication protocol assumes that the entity being authenticated can receive a challenge and respond to it intelligently. A human can read a push notification, enter a one-time code, or recognize a phishing attempt and refuse. A temperature sensor cannot. An industrial actuator cannot. A drone mid-flight certainly cannot.
This means the entire MFA ecosystem, which is the primary mechanism by which modern IAM raises assurance levels, is architecturally inapplicable to most IoT devices. The device authenticates once, with whatever credential it was provisioned with, and that is the end of the verification story.
Assumption 2: The principal has a manageable lifecycle
Human identity lifecycle management follows a predictable arc. That is onboarding, role changes, and offboarding. HR systems feed IAM systems. Joiners get provisioned. Leavers get deprovisioned. The process is imperfect in practice, but the framework exists and is broadly understood.
Device identity lifecycle is a different problem entirely. Devices are deployed at scale, thousands at a time, often in physically inaccessible locations, and they run autonomously for years. Credential rotation, which is a routine operation for human accounts, becomes a significant engineering challenge when the credential lives on a microcontroller bolted inside an industrial machine or embedded in a pipeline sensor forty meters underground. The result is that device credentials are frequently static for the entire operational lifetime of the device, which can be a decade or more.
Assumption 3: Anomalous behavior triggers a human response
When a human account behaves unusually, for example, logs in from an unexpected country, or accesses sensitive resources outside normal hours, a human is notified. They investigate. They make a judgment call. The system supports the human; the human makes the decision.
There is no human equivalent on the other end of a device identity. A compromised IoT device will not notice that it is behaving unusually. It will not file a support ticket. It will keep doing what it is doing. Publishing data, accepting commands, consuming resources, until something external detects the deviation and intervenes. And in most current deployments, nothing is watching closely enough to catch it.
The cumulative effect
Strip away MFA, compress the lifecycle management, remove the human in the loop, and what you are left with is an identity framework operating on assumptions that were never designed for the environment it is now being asked to secure.
The credentials exist. The authentication events happen. The continuous, behavioral, runtime validation that Zero Trust demands is simply absent.
This absence is not a configuration issue, but a structural problem that makes IDoT one of the genuinely open research problems in identity security right now.
The IDoT Attack Surface Nobody Talks About
Credential theft, lateral movement, and the device that's been compromised for eight months
The dramatic botnet attacks, DDoS amplification, and ransomware hitting hospital equipment tend to dominate the security convention around IoT. These are real threats, but they are also the visible ones. The more insidious risk in IDoT environments is quieter, slower, and far harder to detect.
The static credential problem
A device credential that never rotates is not just a hygiene issue, but also an open invitation for threats. Once an attacker extracts a certificate or token from a device through physical access, firmware extraction, a supply chain compromise, or a vulnerability in the device's update mechanism, they hold something that will remain valid indefinitely. There is no behavioral monitoring flagging the credential's sudden appearance in an unexpected location. The credential works, so the system trusts it. The breach is invisible.
This is not a theoretical scenario. Credential extraction from IoT firmware is a well-documented attack technique. The challenge is not that it is sophisticated in most cases. The challenge is that the window of exposure between compromise and detection is measured not in hours or days but in months.
Lateral movement through device identities.
Device identities are rarely isolated. A sensor reporting to a gateway, a gateway publishing to a broker, a broker feeding a backend analytics platform, each hop in that chain is an authenticated connection, and each authenticated connection is a potential pivot point.
An attacker who compromises a single edge device does not necessarily want that device. They want what it can reach. A legitimate device identity with valid credentials and established communication patterns is a nearly frictionless path through network segmentation that would otherwise block an unknown principal. The device is trusted. Its traffic is expected. Its connections are whitelisted. The attacker moves laterally behind that cover, and nothing raises an alert because nothing looks wrong.
The eight-month problem
Perhaps the most uncomfortable reality in IDoT security is the detection latency. In environments without continuous behavioral monitoring of device identities, compromise can persist for an extraordinary length of time before anything surfaces. The device continues its normal functions alongside whatever malicious activity has been layered on top. Periodic security scans check whether the credentials are valid. Perimeter monitoring checks whether traffic is coming from a known device. Nothing in the conventional security stack is asking whether the device is still behaving like itself****.
By the time the compromise is discovered, often through an unrelated incident, an anomaly in downstream data, or a tip rather than automated detection, the attacker has had months of uncontested access. The damage is done! The audit trail is cold!
The gap between where we are and where we need to be
Solving IDoT security is not about finding a smarter perimeter. It is about accepting that device identity is not a provisioning event, where it is a continuous, runtime property that needs to be earned, monitored, and re-validated throughout the operational lifetime of the device.
Yet the reality in most deployments today looks nothing like that. Credentials are static. Lifecycles are unmanaged. Behavioral baselines do not exist. And when something does go wrong, the detection latency is measured in months rather than minutes. Not because the signals aren't there, but because nobody built the infrastructure to read them.
The things on your network have identities. Most of them are unmanaged, unmonitored, and one extracted credential away from becoming an attacker's most valuable asset. That is not a future problem. It is the current state of IDoT security.
References
https://thehackernews.com/expert-insights/2026/05/the-non-human-identity-crisis-why-your.html