What Happens When a Tractor Needs an Identity?
Contents
Most identity programs were built for people. Employees, customers, contractors, and administrators sign in, prove who they are, and receive access that someone can later review.
That model no longer describes most of the identities touching critical systems. Devices, workloads, APIs, service accounts, robots, sensors, and AI agents now read data, initiate transactions, and in some industries move physical equipment. In most enterprises they already outnumber human identities, and they are rarely governed with the same rigor.
Identity Fusion confronted this problem while working with a global agricultural equipment manufacturer building a precision agriculture platform. The platform connected farmers, dealers, suppliers, employees, and tens of thousands of connected machines across the United States. At the time, the project was called an Internet of Things initiative. Today we would call it what it was: a non-human identity program, built before the industry had a name for one.
When a Tractor Becomes an Identity
Precision agriculture combines connected machinery, sensors, cloud applications, and analytics to make farming more efficient. A soil sensor reports moisture and triggers irrigation. A harvester reports yield row by row. A tractor reports its own condition and alerts both the farmer and the dealer when service is due. The payoff is higher yields, less water and fertilizer, and fewer breakdowns at harvest.
Each of those exchanges is an identity event. When a tractor submits data, receives instructions, or calls an API, it is acting as a digital identity that must be recognized and trusted. Yet it cannot type a password, approve an MFA prompt, or call the help desk when its credentials expire.
The lifecycle is also nothing like an employee's. A tractor may run for decades, sit idle for a season, change owners at a dealership, and eventually be scrapped. Every one of those moments changes who should trust the machine and what it should be allowed to do.
Authentication Is the Easy Part
It is tempting to treat non-human identity as a credential problem: issue a certificate, key, or token and let the device connect. That solves authentication and little else. A mature program can answer four sets of questions for every non-human identity:
Know it. What is this entity, who owns it, and who is accountable for it?
Trust it. How was its identity established, what credential was issued, and where is that credential protected?
Control it. What systems and data may it reach, what actions may it take, and who reviews that access?
Retire it. What happens when it is transferred, compromised, replaced, or decommissioned?
An organization that cannot answer these questions does not manage its non-human identities. It simply lets machines connect.
The Architecture: A Chain of Trust from Enrollment to API
The solution combined three identity capabilities, each with one job. Identity management owned the lifecycle, the directory held the authoritative profile, and access management decided what each machine could do.
Every API call traces back to a provisioned identity
Enroll. Identity management created the machine's identity, captured its profile, such as model and owning operation, and issued its credential. The directory stored the profile and the material needed to verify the credential, not a recoverable secret.
Authenticate. The machine presented its credential to a protected endpoint on the access management platform.
Evaluate. Access management verified the credential and retrieved the machine's profile and relationships from the directory.
Issue a token. Policy turned those attributes into a scoped token whose claims described the machine and exactly what it was permitted to do.
Call the API. The machine presented the token to platform APIs, which validated it and enforced its scope. Every request was logged against the machine's identity.
The design choice that matters most for leadership: no platform service trusted a device directly. Every service trusted the token, and the token reflected policy the business controlled centrally. Changing what a class of machines could do meant changing one policy, not every application.
Authorization Is Where Trust Becomes Control
Knowing a device is authentic does not mean it should be able to do everything. The policy model limited each identity to its purpose:
A moisture sensor can submit readings but cannot change equipment configuration.
A harvester can report yield for the operation that owns it, and nothing about any other farm.
A dealer can receive maintenance telemetry for the machines it services, but not the farmer's agronomic or financial data.
The last example is the hardest and the most important. Agriculture runs on three-way relationships among a machine, the farmer who owns it, and the dealer who services it. Access had to follow those relationships, not just the device's credential, and change automatically when the relationships changed.
Without this layer, strong authentication creates false confidence. The organization knows what is connected but has no control over what those connections can do.
When the Tractor Changes Hands
Most device programs stop at onboarding. The harder problems come later, and they are where lifecycle management earns its keep. Because the lifecycle lived in the identity management layer rather than inside each application, a change made once took effect everywhere.
Transfer. When a machine is traded in or resold, its identity persists but its relationships change. The previous owner loses access, the new owner and dealer gain it, and historical data stays with the party entitled to it.
Compromise. A single machine's credential can be revoked and reissued without disrupting the rest of the fleet.
Retirement. A decommissioned machine's credentials are revoked and its identity is disabled, while its record is retained for audit.
This is the difference between connecting devices and governing them.
The Business Outcome
Identity became the path every new machine, dealer, and supplier took onto the platform. Growth no longer waited on identity work. The identity foundation was what made growth safe to pursue.
New equipment shipped connected by default. Adding a model or product line meant enrolling it into an existing trust framework, not building a new one.
Partners integrated faster. Dealers and suppliers connected through the same policy model, with access scoped to their relationships.
Every machine interaction was auditable. Authentication and API access were logged against a known identity, supporting monitoring, incident investigation, and compliance.
The manufacturer could expand its digital services without revisiting identity each time. That is the return on a mature non-human identity strategy: it reduces risk and gives the business a trusted foundation to build on.
Yesterday's IoT Challenge Is Today's NHI Priority
Swap the tractor for a medical device, a trading bot, a warehouse robot, or a connected vehicle, and the architecture holds. The same principles apply to the non-human identities most enterprises already run: service accounts, cloud workloads, API clients, and now AI agents.
AI agents raise the stakes. A tractor follows its programming; an agent decides what to do next. When an identity can choose its own actions, authorization stops being a control and becomes the primary safeguard.
What has changed since this engagement is scale and autonomy. Cloud adoption, automation, microservices, and AI are creating non-human identities faster than traditional governance can track. Many organizations have no reliable inventory of them, let alone consistent control over their credentials and access.
The principle has not changed. Every identity, human or otherwise, must be known, trusted, governed, and limited to the access it genuinely needs. The identities helping feed the world may not be human, but securing them remains a very human responsibility.
Identity Fusion helps organizations build this same foundation: an inventory of their non-human identities, lifecycle control over their credentials, and policy-based limits on what each one can do, whether it is a tractor, a workload, or an AI agent. If you are assessing your non-human identity exposure, let's talk about where your greatest risks are.