Why do zero-trust programmes need to treat NHIs and IoT devices differently from users?

Why zero-trust must distinguish machine trust from user trust

zero trust is not just “more authentication.” For NHIs and IoT devices, the trust problem is the device or workload itself, not a person signing in. That means the programme has to validate identity, software posture, certificate state, network location and expected behaviour continuously, not only at login or at session start.

For users, the control point is often an interactive session. For machines, the control point is usually an automated exchange, an API call or a device-to-service relationship that can run for long periods without interruption. If a zero-trust design treats those as equivalent, it will overestimate what one-time login assurance can prove and underestimate the value of runtime policy.

That distinction is visible in NIST SP 800-207 Zero Trust Architecture, which emphasises continuous verification, least privilege and policy decisions made from current context rather than a single trust event. For machine traffic, that is the difference between trusting a person’s momentary intent and trusting a device or service to keep behaving as expected after the first check. The same logic is explored in NHIMG’s Zero Trust Identity Guide and Zero Trust for AI Agents.

What changes for NHIs and IoT devices in practice

NHIs and IoT devices usually have their own lifecycle, credential type and failure modes. A service account, workload identity or device certificate can persist far longer than a human session, can be reused by automation and can be embedded in code, firmware or orchestration layers. That changes the zero-trust question from “Did this actor authenticate?” to “Is this actor still authorised, still in the right state and still operating within its intended scope?”

IoT devices add another constraint: the device state itself matters. Hardware root of trust, secure boot, attestation, firmware integrity and onboarding controls can be as important as the credential. The programme has to know whether the device is the right model, running approved software and still compliant with policy before it can be trusted for access. NHIMG’s Device and IoT Identity Guide and Service Account Security Guide are useful references for those control differences.

For NHIs, credential scope and rotation cadence often matter more than user convenience. If a token, API key or certificate is broad, long-lived or shared across environments, the blast radius is much larger than a normal user login failure. NHIMG’s Guide to NHI Rotation Challenges and IAM and IGA Basics both reinforce that lifecycle and entitlement control are part of the trust model, not an administrative afterthought.

How zero trust should model machine risk, not just machine access

The core mistake is to map machine trust to a user-style sign-in model and stop there. A machine can be authenticated correctly and still be dangerous if it is overprivileged, operating from an untrusted environment or carrying credentials that never expire. In practice, zero trust should tie access to the thing that is changing: the credential, the workload, the device state or the policy context.

That is why the architecture has to treat scope as first-class. A device that is healthy but only meant to reach one service should not inherit broad network access. A workload that is correctly attested but compromised at runtime should not retain the same privileges just because its initial authentication was valid. NHIMG’s Ultimate Guide to NHIs, Key Challenges and Risks is useful here because it frames the practical issues as visibility, sprawl and over-privilege, not simply “bad authentication.”

Zero trust also has to recognise that NHIs and IoT devices are often the connective tissue between systems. That makes them attractive pivot points when credentials are stolen or device trust is weakened. The right design therefore treats every machine-to-machine relationship as a separate policy decision, with explicit validation of identity, posture and expected behaviour rather than inherited trust from a user context.

Practitioner Guidance

What to verify: Check whether the programme can answer three questions for each NHI or IoT path, what is the entity, what state must it be in to be trusted, and what scope is it allowed to reach. If any of those are unclear, the zero-trust design is still user-centric rather than machine-centric.

Decision rule: If a machine credential can authenticate without proving device state, software integrity or current policy compliance, treat the trust model as incomplete. If it can authenticate and reach multiple services by default, treat that as a privilege problem, not just an authentication problem.

What good looks like: Machine access is short-scoped, observable and revocable, with separate controls for identity proof, posture checking and runtime authorisation. The best sign of maturity is that a stolen machine credential does not automatically imply broad, persistent access.

Practitioner takeaway: Zero trust for humans can centre on sessions, but zero trust for nhis and IoT devices must centre on ongoing state, scope and runtime behaviour, or the programme will trust the wrong thing at the wrong time.

Related resources from NHI Mgmt Group

• What is the difference between zero trust for users and zero trust for NHIs?
• Why do NHIs complicate zero trust and least privilege efforts?
• What is the difference between JIT access and Zero Trust for NHIs?
• How should teams govern Zero Trust across users, devices, applications, and NHIs?