IoT users: managing the identity of billions of connected devices

For decades, digital identity management in businesses has mainly concerned people. An employee receives an account when joining the organization, obtains access corresponding to their role, sees their permissions change when they move into a new function, and normally loses their access when they leave the company. This lifecycle management is today one of the foundations of cybersecurity.

The Internet of Things considerably changes the scale of the problem. Sensors, cameras, vehicles, industrial machines, medical equipment, energy systems, and other connected devices must now be recognized by the infrastructures they communicate with. They must be able to prove their identity, access the resources required for their function, and be prevented from using those that are not intended for them. Their permissions must also be able to evolve or be revoked throughout their lifetime.

To this population of devices are added applications, APIs, automated services, and now artificial intelligence agents. A digital business may therefore gradually administer far more non-human identities than human ones.

This change may seem essentially technical. It is nevertheless fundamental. When a machine has an identity, permissions, and the ability to act, it becomes a participant in the digital infrastructure. Identity management can therefore no longer be organized primarily around a single question: “Who is this user?”

It must now continuously answer a far broader question: what is trying to access our systems, and what are we prepared to let it do?

A connected device faces a problem comparable to that of a human user when it wants to access a resource. When a sensor transmits data to a platform, the platform must be able to determine that it really is the expected device. When a machine requests a configuration or a vehicle communicates with a remote service, the infrastructure must be able to establish the legitimacy of that communication.

A simple network address is not a sufficiently reliable identity. It can change, be spoofed, or provide only very limited information about the equipment that is communicating. Various mechanisms therefore make it possible to bind a digital identity more solidly to the device: certificates, cryptographic keys, secure modules, provisioning mechanisms, or identities associated with certain connectivity infrastructures.

This identity is, however, the beginning of the trust relationship, not its conclusion.

A system can establish with a high level of confidence that a device does indeed hold the identity it claims without having to automatically accept all of its actions. A legitimate device can be compromised. Its software may contain a vulnerability, a key may have been exposed, or its behavior may suddenly become inconsistent with its usual function.

This distinction between authentication and authorization becomes fundamental. Identity makes it possible to determine who or what is requesting access. Security policies then determine what that identity can actually do in a specific context.

A sensor whose job is to transmit a temperature has no reason to access the company's entire network. A camera may need to send images to a particular service without being able to consult other systems. A piece of industrial equipment may receive certain operational commands while remaining isolated from the administrative functions it has no reason to access.

Identity thus becomes the starting point for least privilege. The challenge takes on a completely different dimension, however, as the number of devices grows. A company with a few thousand employees may already devote considerable resources to managing its accounts, roles, and permissions. An organization operating tens or hundreds of thousands of devices must manage a digital population on an entirely different scale.

Each device may have a distinct identity, a particular software version, specific authorizations, and a specific relationship with different systems. Some devices are added, others replaced. They may change location, owner, or function. Some fail, are compromised, or must be deactivated.

Essentially manual management quickly becomes impossible. Machine identity must therefore be designed from the outset to work at scale. Provisioning, secret renewal, permission changes, and revocation must be capable of automation while retaining enough control and traceability to understand precisely what is happening. An architecture capable of administering a hundred devices does not automatically become an architecture capable of administering a hundred thousand.

This scale also requires thinking of identity as a lifecycle. A digital identity should never be considered permanent simply because it belongs to a machine. When a device is manufactured, an initial identity must be created or established. At deployment, it must be associated with an environment, a customer, an organization, or a function. Its permissions may then evolve over several years.

The device may change owner or site. A new function may be assigned to it. Its cryptographic keys will eventually need to be renewed, and its certificates will expire. A vulnerability or a security incident may require the immediate revocation of certain access. Then will finally come the moment when the equipment is taken out of service.

The way its identity disappears then becomes as important as the way it was created. A decommissioned device that retains valid credentials can become an entry point into systems that continue to regard it as legitimate.

This question becomes particularly complex when devices have a lifespan of ten or fifteen years. The identity and cryptography technologies used when they were manufactured may need to evolve several times during their operational life. A robust architecture must therefore provide, from the design stage, for the ability to renew credentials, modify permissions, and replace certain cryptographic mechanisms.

Initial provisioning is also a critical step. A device may be manufactured several months before its installation, pass through various intermediaries, and finally be deployed in an environment unknown to the manufacturer at the time of production. Permanently embedding sensitive credentials in the software or using static secrets then creates significant risks.

Sharing a single secret across several devices can considerably extend the consequences of a compromise. Using a different secret for each device improves separation, but then requires the ability to manage potentially millions of credentials over several years.

More dynamic approaches make it possible to use the device's initial identity to establish a first trust relationship, and then obtain the credentials and permissions actually needed for its operational environment. The device therefore does not need to permanently hold every key granting direct access to each platform it might use.

Identity then becomes less a vault holding all the keys than a mechanism for obtaining the appropriate authorization when it is needed. This design connects directly to the principle of Continuous Trust. In a distributed infrastructure, identity makes it possible to initiate the relationship, but trust must be able to evolve with the context. A device correctly authenticated yesterday may have changed state today. Its configuration, its location, its behavior, its software version, or its risk level may justify a different decision.

Trust therefore becomes continuously verified and reassessed rather than permanently acquired. This capability also has a digital sovereignty dimension. Who controls a device's identity? Who can modify or revoke it? Is it tightly bound to a particular vendor? Can it continue to work if the organization changes network, platform, or cloud provider?

These questions take on considerable importance when devices remain in service for a decade or more. A company may change its technology strategy several times during that period. It may migrate to another cloud infrastructure, modify its management systems, change carriers, or have to meet new regulatory requirements.

If the identity of an entire fleet is deeply dependent on an infrastructure that is practically impossible to replace, the devices themselves become a source of technological dependency. Preserving the ability to evolve identities, permissions, and trust relationships therefore contributes directly to preserving the ability to choose.

IoT devices nevertheless represent only part of this transformation. Organizations already hold many technical identities associated with applications, services, APIs, and automations. The arrival of AI agents broadens this population further, because these systems can consult several sources of information, use applications, and trigger actions on behalf of a process or a team.

An agent may need to consult a CRM, access a document repository, prepare a transaction, or trigger an operation in another system. It therefore needs a clearly defined identity and permissions.

This situation raises an important question: should the agent use the identity of the employee who launched it, or have its own identity? A distinct identity generally allows for far more precise governance. The organization can define exactly what the agent is authorized to do, track its actions, and revoke its permissions independently of those of the human user.

This separation becomes particularly important when several agents collaborate with one another or begin interacting with IoT devices.

Imagine an industrial infrastructure in which a sensor detects a situation. The data is transmitted to a platform where an AI agent analyzes it, consults the machine's history, and determines that an intervention is necessary. An instruction is then sent to a control system that modifies certain operating parameters.

Several identities then take part in a single chain of action: the sensor that produced the information, the platform that received it, the agent that interpreted it, the system that requested the intervention, the equipment that carried it out, and possibly the employee who supervised the process.

The organization must be able to reconstruct that chain. It must know which identity produced the information, which one made or recommended a decision, which one requested the action, and which system finally executed it. As systems become autonomous, knowing who—or what—did what becomes an essential property of security, governance, and accountability.

This multiplication of non-human identities inevitably increases the number of potential targets. A resilient architecture therefore cannot rest on the assumption that no identity will ever be compromised. It must limit the consequences when a compromise does occur.

If a sensor is compromised, its identity should allow access only to the resources needed for its function. If an AI agent is hijacked, its permissions should prevent it from acting beyond its mandate. If a key is exposed, it must be able to be revoked and replaced quickly.

This is where IAM, least privilege, segmentation, Zero Trust, and Continuous Trust come together. The objective is to prevent a legitimate identity from becoming a master key allowing free movement across the digital environment.

This transformation also creates a far more fundamental need: organizations will have to know which identities exist.

A device inventory is no longer enough. How many machine identities are active? Which systems do they give access to? Who is responsible for them? When were they created? Which certificates and cryptographic mechanisms do they use? When must these be renewed? Do some identities correspond to equipment that is no longer in service?

These questions become particularly important from the perspective of a cryptographic transition. An organization that must replace an encryption or signature mechanism needs to know the devices, certificates, applications, and systems that depend on it. Machine identity therefore connects directly to crypto-agility and post-quantum readiness.

A company that does not know where its identities are and what their cryptographic dependencies are will inevitably run into greater difficulty when it has to make them evolve.

This evolution finally leads us to reconsider the very role of identity in IT architecture. As systems become distributed, the physical network loses part of its historical role as a trust boundary. A device may be connected over cellular, satellite, Wi-Fi, or Ethernet. An agent may run in a public cloud, a private infrastructure, or directly at the Edge.

Location is no longer enough to establish trust. Identity then becomes one of the mechanisms for maintaining a consistent policy across these environments. A system can recognize a human, a device, an application, or an agent, verify its context, and apply the appropriate permissions regardless of where it is located.

Identity is gradually becoming an infrastructure in its own right.

It is no longer simply the mechanism that lets an employee log in each morning. It is becoming one of the foundations that allow people, machines, applications, and artificial intelligences to work together while retaining exactly the level of authority their role requires.

Organizations are entering a period in which digital identities will no longer mainly represent people. They will also represent sensors, machines, vehicles, applications, APIs, automated services, and artificial intelligence agents. In some organizations, this non-human population could quickly exceed the number of employees by a wide margin.

Managing these identities is therefore becoming a strategic discipline. Every device and every agent must be able to be recognized, authenticated, limited to its role, supervised throughout its lifetime, and revoked when it should no longer access the systems. This governance will have to work at very large scale while retaining enough precision to determine which identity performed which action.

This evolution is also one of the foundations of Hypersecurity. When infrastructures become distributed and intelligent, trust can no longer depend primarily on network location. It must rest on known identities, controlled permissions, continuously assessed context, traceable interactions, and the ability to quickly contain the consequences of a compromise.

At Quantum Beyond, this transformation connects directly to our work in security architecture, IAM, Zero Trust, Continuous Trust, Q-Carbon Security Systems, Edge infrastructures, AI agent governance, and cryptographic readiness. Our experts work alongside technology and cybersecurity teams to strengthen existing architectures, structure trust relationships, and prepare organizations to manage environments where human identities will soon represent only part of the digital ecosystem.

For a long time, cybersecurity sought mainly to answer one question: “Is this really the right person?”

In an infrastructure where humans, devices, applications, and intelligent agents work together, the question becomes more demanding: “Is this really the right person, the right machine, or the right agent, in the right context, and does it hold exactly the level of authority needed to carry out this action?”