Start with a baseline inventory of everything that can connect to the environment, including owned assets, shadow IT, and third party systems. Zero Trust fails quickly when teams skip this step because they cannot scope risk, define policy boundaries, or monitor what they cannot see. The first practical goal is to establish an accurate inventory before tightening access controls.
Why Inventory Comes First in a Zero Trust Start
zero trust is built on explicit knowledge of what is connecting, what it is allowed to access, and where policy must be enforced. When the inventory is incomplete, every downstream decision is guesswork, including segmentation, conditional access, and exception handling. Start by enumerating owned devices, unmanaged endpoints, cloud workloads, shadow IT, and third-party connections that can touch the environment.
A reliable starting inventory does not need to be perfect on day one, but it must be broad enough to expose the real attack surface. That usually means combining discovery from network telemetry, endpoint tooling, cloud control planes, identity logs, and procurement or vendor records. The important shift is from a trust-based operating model to a measured one, where unknowns are treated as risk until proven otherwise.
For teams already struggling with visibility, a useful benchmark is that only 5.7% of organisations have full visibility into their service accounts in NHI Mgmt Group’s Ultimate Guide to NHIs. That is a reminder that the inventory problem is usually broader than laptops and servers, because hidden accounts and machine-access paths often carry the most privilege.
What to Include in the First Pass Inventory
The first pass should capture every asset class that can participate in access decisions, not just managed hardware. That includes laptops, virtual machines, containers, cloud services, APIs, SaaS tenants, remote support tools, and any third-party system with persistent connectivity. If the environment depends on it for authentication, data exchange, remote administration, or policy enforcement, it belongs in scope.
Practically, this is where teams should build a minimal classification model, for example: known and managed, known but unmanaged, and unknown. That simple structure helps separate remediation priorities from long-term normalisation work. It also reveals where policy can be enforced immediately and where compensating controls or temporary containment are needed.
NHIMG’s Ultimate Guide to NHIs, Key Challenges and Risks is directly relevant here because inventory gaps often include service accounts, API keys, and other non-human access paths that do not show up in a traditional device list. The same guide’s lifecycle section also helps teams think beyond discovery into ownership, rotation, and revocation.
For workload-level visibility and attestation, teams that run service meshes or zero-trust internal service fabrics can also look at the Guide to SPIFFE and SPIRE, which is useful when the inventory problem extends to workload identity and service-to-service trust.
Sequencing the Programme Without Waiting for Perfection
A sensible sequence is: discover, validate, classify, then apply policy. Discovery finds the assets, validation confirms who owns them and whether they are still active, classification determines which access rules apply, and only then should policy tighten. If you reverse that order, teams usually create blind spots, emergency exceptions, and operational friction that erodes confidence in the programme.
The control objective is to get enough certainty to make policy real. That means identifying the handful of systems that can reach sensitive data or administrative functions first, because they define the highest-risk trust boundaries. It is better to have an incomplete but reviewed inventory of critical assets than a broad but untrusted catalogue that no one maintains.
As the scope expands, connect the inventory process to ownership and change management so that new assets are registered at creation, not discovered after the fact. In Zero Trust, the inventory is not a one-time project deliverable, it is part of the operating model that keeps policy, monitoring, and access decisions aligned with reality.
Risk and Threat Considerations
An unreliable inventory creates immediate exposure because policy enforcement depends on knowing what exists. Unknown systems can bypass segmentation assumptions, unmanaged third-party links can retain access long after they should be removed, and shadow infrastructure can become an easy path for lateral movement or data exfiltration.
Failure mechanism: security teams assign trust boundaries, access rules, or monitoring coverage to an incomplete asset list, leaving uncounted endpoints, services, or external connections outside policy and detection.
Impact: attackers can hide in unmanaged assets, privileged access may persist unnoticed, and the Zero Trust programme can give a false sense of control while the real attack surface remains partially invisible.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST Zero Trust (SP 800-207), NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST Zero Trust (SP 800-207) | 0 — Zero Trust Architecture | Zero Trust depends on knowing assets, policy boundaries, and enforcement points. |
| Recommendation — Establish a verified asset baseline before tightening access policies and trust boundaries. | ||
| NIST CSF 2.0 | ID.AM — Asset Management | Asset inventory is the foundation for identifying what must be protected and governed. |
| Recommendation — Build and maintain an accurate inventory of devices, software, and external dependencies. | ||
| CIS Controls v8 | 1 — Inventory and Control of Enterprise Assets | CIS Control 1 directly addresses the missing inventory problem at the start of Zero Trust. |
| Recommendation — Discover, inventory, and track all enterprise assets before enforcing stricter access controls. | ||
| OWASP Non-Human Identity Top 10 | NHI-02 — Inventory and Discovery | Unknown service accounts and keys can hide critical access paths in the inventory gap. |
| Recommendation — Discover and catalogue non-human identities and their credentials before policy enforcement. | ||
Practitioner Guidance
What to prioritise: start with the systems that can reach sensitive data, administrative interfaces, or production workloads, because those assets define the highest-value trust boundaries. If a platform can authenticate, proxy, or relay access for others, it belongs near the top of the list even if it is not a traditional endpoint.
What to verify: for each discovered asset, confirm ownership, business purpose, connectivity, and whether it is still active. Unknown ownership is a stronger blocker than unknown technology, because unowned assets tend to remain unremediated and unpatched.
Practitioner takeaway: the programme should be judged by whether it turns unknown connectivity into governed connectivity, not by whether it produces a perfect catalogue on the first attempt.
Related resources from NHI Mgmt Group
- How should security teams start Zero Trust without creating tool sprawl?
- How can security teams tell whether their identity programme is ready for zero trust?
- How should security teams implement integrated PAM in a zero trust programme?
- How should security teams combine RBAC and ABAC in a Zero Trust programme?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 20, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
