What happens when organisations try to move to Zero Trust without first mapping devices, identities, and non-human accounts?

Why Zero Trust fails when the inventory is missing

Zero Trust depends on knowing what is being protected and who or what is allowed to reach it. If the inventory is incomplete, policy decisions are made against a partial picture, so teams can harden one path while leaving another path, account, or device untouched. The result is not just weaker security, it is inconsistent enforcement that creates blind spots across the environment.

That is why NIST SP 800-207 Zero Trust Architecture remains the anchor reference for this problem, because the model assumes explicit control over subjects, resources, and access decisions rather than blind trust in the network perimeter. NIST SP 800-207 Zero Trust Architecture

What gets missed when devices, identities, and non-human accounts are not mapped

The missing items are usually the ones that matter most to enforcement. Unowned devices, stale accounts, orphaned group memberships, service accounts, cloud workloads, containers, virtual machines, and network infrastructure can all retain paths into critical systems even after a team believes it has moved to a trust-minimised model.

That inventory problem is not just theoretical. Zero Trust Identity guidance for people, workloads, and devices works precisely because it forces teams to identify the subject of access before they try to control it. Zero Trust Identity Guide and the companion analysis in IAM and IGA Basics both reinforce that identity, entitlement, and lifecycle governance have to be visible before policy can be dependable.

When the environment includes non-human accounts, the issue becomes broader than user access. Service accounts, machine identities, and application credentials can outlive the systems that created them, or remain active after ownership has changed, so the Zero Trust project never gets a clean starting line. Ultimate Guide to NHIs, What are Non-Human Identities is useful here because it frames those accounts as part of the access surface, not an exception to it.

Why the gap turns into control drift instead of simple visibility loss

Once the inventory is incomplete, policy drift follows. Teams may remove access from the identities they know about, while unknown devices or machine accounts continue to authenticate, inherit permissions, or sit inside broad groups. In practice, that means the trust model becomes uneven, some paths are policy-driven, and others remain effectively implicit.

For device and workload-heavy environments, the omission is especially dangerous because the control surface includes more than usernames. Device and IoT Identity Guide and Guide to SPIFFE and SPIRE both show that device trust and workload identity need explicit representation before attestation, certificates, or service-to-service access can be governed consistently. Without that baseline, Zero Trust ends up protecting the labelled assets while leaving the unlabeled ones to inherit old access paths.

Risk and Threat Considerations

Incomplete mapping creates a durable attack surface because adversaries often prefer the assets defenders do not enumerate well, especially stale service accounts, forgotten devices, and broad group memberships that still reach production systems. In a Zero Trust programme, that gap can undermine segmentation, exception handling, and incident containment at the same time.

Failure mechanism: Unknown or unmanaged assets keep existing trust relationships, so policy is enforced only against the visible subset while the hidden subset remains reachable through inherited access, long-lived credentials, or unmanaged network paths.

Impact: Attackers can move through those overlooked paths, maintain persistence, or bypass intended least-privilege controls, and defenders may not detect the exposure until a later audit or incident.

Practitioner Guidance

What to prioritise: Start with a baseline that separates owned from unowned assets and distinguishes human accounts from service, workload, device, and infrastructure identities. A Zero Trust rollout should not begin with policy tuning alone; it should begin with asset and identity enumeration that is good enough to support enforcement.

What to verify: Check whether every access path can be tied back to a named owner, a defined purpose, and a reviewable lifecycle. If a device, container, VM, or non-human account cannot be assigned to an accountable owner, treat it as a governance gap before you treat it as a technical tuning problem.

Practitioner takeaway: Zero Trust is only as strong as the inventory beneath it, because policy cannot be consistently enforced against identities and devices the organisation has not first made visible.

Related resources from NHI Mgmt Group

• What happens when organisations try to use zero trust without changing access control first?
• What happens if organisations try to enforce zero trust segmentation without first understanding endpoint traffic patterns?
• What happens when organisations try to adopt Zero Trust without defining scope first?
• Why do non-human identities create more audit risk than human accounts?