NSA Zero Trust discovery makes identity inventory the first control

At a glance

What this is: The NSA’s new Zero Trust guidance turns discovery into the prerequisite for policy-driven enforcement across users, devices, applications, workloads, and data flows.

Why it matters: For IAM, NHI, and Zero Trust teams, it means identity inventory, telemetry, and authoritative policy data are no longer supporting activities but foundational controls.

By the numbers:

• 90% of IT leaders say properly managing NHIs is essential for a successful zero-trust implementation.
• Only 5.7% of organisations have full visibility into their service accounts.
• 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.

👉 Read Appgate's analysis of the NSA Zero Trust discovery guidelines

Context

Zero Trust discovery is the work of finding out what actually exists before trying to enforce policy across it. That matters because identity-centric access only works when organisations have authoritative visibility into users, non-person entities, devices, applications, data, and traffic flows, which is exactly the gap the NSA is trying to close in its January 2026 guidelines.

The practical shift is from abstract Zero Trust language to operational prerequisites: inventory, telemetry, policy mapping, and accountable ownership. For identity programmes, that means discovery is not a preliminary exercise to be deferred, but the control layer that determines whether later enforcement, recertification, and least-privilege decisions are defensible at all.

Key questions

Q: How should organisations start a Zero Trust programme when identity data is incomplete?

A: Start with discovery, not enforcement. Build authoritative inventories for users, service accounts, devices, applications, workloads, and data paths, then map ownership and access boundaries. Without that baseline, least privilege and continuous verification become assumptions rather than controls, and policy decisions will be too brittle to trust.

Q: Why does Zero Trust depend so heavily on identity visibility?

A: Because every Zero Trust decision depends on knowing who or what is requesting access, what context applies, and whether that context is current. If identity visibility is weak, policy engines inherit blind spots and the environment falls back to implicit trust, even when the architecture is labelled Zero Trust.

Q: What do security teams get wrong about discovery in Zero Trust?

A: They often treat discovery as a one-time inventory exercise instead of a continuous governance function. In practice, assets, identities, entitlements, and telemetry change constantly, so discovery must support ongoing policy validation, recertification, and exception handling or the control model decays quickly.

Q: Who is accountable when Zero Trust controls fail because discovery was incomplete?

A: Accountability usually sits with the teams responsible for identity governance, asset ownership, and control validation, not with the technology alone. If inventories are stale or ownership is unclear, the failure is structural. Practitioners should assign explicit accountability for identity data quality before expanding enforcement.

Technical breakdown

Why Zero Trust discovery comes before enforcement

Zero Trust architectures depend on continuous verification, but verification is only as strong as the underlying identity and asset data. Discovery is the process of building authoritative inventories of users, devices, applications, workloads, data stores, and traffic paths so access policy can be applied to real conditions rather than assumptions. The NSA’s guidance effectively formalises this sequencing by treating visibility and telemetry as prerequisites for policy execution. In identity terms, that means you cannot govern what you cannot reliably enumerate, classify, or observe.The deeper point is that Zero Trust is not a perimeter redesign. It is a control model that relies on accurate context at decision time. If discovery is incomplete, the policy engine inherits blind spots and the programme recreates implicit trust inside a modern stack.

Practical implication: build authoritative inventories and telemetry first, then tie every access control decision to those sources.

How identity-first policy changes the control plane

Identity-first access means the decision to allow or deny access is based on who or what is asking, what device or workload is involved, and what context is present at that moment. In the NSA model, that includes users and non-person entities, not just human logins. For IAM and NHI programmes, this turns identity into the control plane that routes access across applications and services. The policy layer must therefore understand both entitlements and runtime context, or it will default to broad access that is hard to audit.Granular policy also depends on clear ownership. If a service account, workload, or application cannot be mapped to a business function and a data scope, least privilege remains theoretical.

Practical implication: align each identity type to a named owner, business purpose, and explicit access boundary.

What telemetry must exist before a zero-trust rollout

Telemetry is the evidence layer for Zero Trust. It covers authentication events, device posture, application access, data movement, network flows, and policy outcomes, allowing teams to validate whether controls behave as intended. The NSA’s discovery phase highlights that logging alone is not enough; the data must be usable for analysis, policy development, and enforcement tuning. In practice, this is where many programmes fail, because they collect logs without creating a decision-quality view of identity behaviour.The consequence for practitioners is clear: if telemetry cannot explain who accessed what, from where, under which policy, and with what result, the organisation cannot prove that Zero Trust is actually operating.

Practical implication: define the minimum evidence set for access decisions before expanding Zero Trust enforcement.

Threat narrative

Attacker objective: The attacker objective is to exploit visibility gaps so identity and access controls continue to over-grant access after Zero Trust has supposedly been implemented.

1. Entry begins when an organisation assumes it can enforce Zero Trust without first building inventories of users, devices, workloads, and data flows. That blind spot leaves identity and asset relationships unverified at the moment they matter most.
2. Escalation occurs when policy is applied to incomplete telemetry, letting broad entitlements and weakly attributed access persist because the control plane cannot distinguish normal access from excess access.
3. Impact is a brittle Zero Trust programme that looks compliant on paper but still grants implicit trust inside the environment, preserving attack paths that discovery was meant to eliminate.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• Meta AI Instagram Account Takeover — 20,225 Instagram accounts hijacked via compromised Meta AI support chatbot with overprivileged access.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Discovery debt is the new control debt: Zero Trust programmes fail when discovery is treated as a preparatory task instead of the control layer that determines whether enforcement is even possible. The NSA’s guidance confirms that inventories and telemetry are not side inputs, they are the evidence base for every access decision. Practitioners should treat missing discovery as an active governance gap, not an implementation delay.

Identity is the first enforcement boundary: Once policy moves from network segments to users, devices, workloads, and non-person entities, identity becomes the only durable place to anchor access decisions. That changes IAM from a provisioning function into an operating model for continuous verification. The implication is that identity teams must own the quality of the data feeding Zero Trust, not just the lifecycle of accounts and credentials.

Least privilege cannot be validated without observability: A privilege model is only meaningful if the organisation can see what access exists, how it is used, and whether it still matches business need. The NSA Discovery Phase makes clear that policy inventory, logging, and analysis are not optional extras. Practitioners should expect recertification and entitlement reviews to fail if they are not backed by runtime evidence.

NHI governance and Zero Trust are converging: The more organisations rely on service accounts, workloads, API tokens, and automation, the more discovery becomes a machine identity problem as much as a human one. That is why the same operational discipline now spans IAM, NHI governance, and policy analytics. Teams that separate them will keep blind spots in the very places Zero Trust is supposed to close.

Authoritative visibility is a programme capability, not a tool feature: The strongest signal in the NSA guidance is that no single platform can substitute for governance over identity sources, asset inventories, data classification, and policy outcomes. The market is moving toward integrated control planes, but practitioners still need independent ownership of the data model. The lesson is to govern the evidence first, then evaluate tooling against it.

From our research:

• 90% of IT leaders say properly managing NHIs is essential for a successful zero-trust implementation, according to Ultimate Guide to NHIs.
• Only 5.7% of organisations have full visibility into their service accounts, which shows how far most identity programmes still are from dependable discovery.
• That visibility gap is why practitioners should also review NHI Lifecycle Management Guide as they translate Zero Trust discovery into operational governance.

What this signals

Discovery debt will now surface as policy failure. Zero Trust programmes that cannot enumerate identities and access paths will struggle to move beyond pilot status, because enforcement depends on data quality as much as control design. The operational priority is to treat inventory freshness, ownership mapping, and telemetry completeness as programme health indicators, not support tasks.

With 96% of organisations storing secrets outside secrets managers in vulnerable locations including code, config files, and CI/CD tools, the discovery problem extends well beyond interactive user access. Identity and platform teams need a shared evidence model for workloads and non-person entities, or the same blind spot will reappear in automation and deployment paths.

The near-term signal is that Zero Trust maturity will increasingly be judged by how well an organisation can prove identity context at decision time. That makes discovery, policy analytics, and lifecycle governance the same programme in different layers, which is why teams should align their operating model with NIST Cybersecurity Framework 2.0 and NIST SP 800-207 Zero Trust Architecture.

For practitioners

• Inventory identities before policy rollout Build a current inventory of human users, service accounts, workloads, applications, devices, and data paths before expanding Zero Trust enforcement. Link each entity to an owner, purpose, and access boundary so policy decisions can be traced back to accountable records.
• Define evidence requirements for every access decision Specify the logs, posture signals, and entitlement data needed to explain allow and deny decisions. If the evidence cannot show who accessed what, from where, under which policy, and with what result, the programme is not ready for broad enforcement.
• Map non-person entities into the same governance model Bring service accounts, API tokens, and automated workloads into the same discovery and review process used for human access. Use the NHI Lifecycle Management Guide to align provisioning, rotation, and offboarding with Zero Trust policy boundaries.
• Use telemetry to validate least privilege continuously Review whether actual access patterns match expected entitlement scope across applications and workloads. Where telemetry shows repeated policy exceptions or unexplained access paths, tighten the policy model before expanding the Zero Trust perimeter.

Key takeaways

• The NSA’s new Zero Trust guidance makes discovery the control that determines whether enforcement can work at all.
• Identity visibility, telemetry, and ownership mapping are now prerequisite governance functions for both human and non-person entities.
• Practitioners should measure programme maturity by the quality of access evidence, not by how many Zero Trust labels have been deployed.

Key terms

• Zero Trust discovery: Zero Trust discovery is the process of identifying and mapping the identities, devices, applications, workloads, data paths, and telemetry needed before policy enforcement begins. It turns an architecture into something governable by creating the evidence base for access decisions, reviews, and continuous verification.
• Identity-centric access: Identity-centric access is a control model where entitlement decisions are made from authenticated identity, context, and policy rather than from network location alone. In practice, it extends governance to service accounts, workloads, and other non-person entities as well as human users.
• Authoritative inventory: An authoritative inventory is the trusted source of record for identities, assets, and entitlements that a security programme uses to make access decisions. For Zero Trust, it must be current enough to support policy enforcement, recertification, and incident investigation without relying on stale assumptions.
• Telemetry-backed policy: Telemetry-backed policy is access control that is validated against logs, posture signals, and access outcomes rather than static configuration alone. It matters because Zero Trust only remains defensible when the organisation can prove that policy decisions match actual runtime conditions.

What's in the full article

Appgate's full article covers the operational detail this post intentionally leaves for the source:

• A breakdown of how AppGate ZTNA aligns to NSA discovery and policy-driven access expectations.
• Capability-by-capability mapping of identity-centric access, granular enforcement, and continuous verification.
• Implementation context for federal and defense aligned environments that need to translate Zero Trust guidance into access architecture.
• The vendor’s view of how its architecture supports discovery without exposing applications to the network.

👉 The full Appgate post covers discovery activities, ZTNA alignment, and implementation context.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM or identity security programme, it is worth exploring.