Device-based discovery is the practice of identifying installed applications by inspecting the endpoint itself rather than relying only on browser, network, or SaaS connector data. It matters because local software can run without generating the identity signals many governance programmes expect to see.
Expanded Definition
Device-based discovery is the practice of identifying installed applications by inspecting the endpoint itself, using local inventory, agent telemetry, or endpoint management data rather than depending only on browser logs, SaaS connectors, or network traffic. In NHI and IAM operations, this matters because endpoint-resident software may launch service accounts, call APIs, or store secrets without producing the identity signals that cloud-first governance tools expect.
Definitions vary across vendors, because some teams treat device-based discovery as a software inventory function while others use it as a control for uncovering shadow IT, unmanaged service accounts, and locally installed automation. The operational distinction is that this approach observes what is actually present on the device, not just what is visible in a directory, browser, or network perimeter. That makes it especially relevant in hybrid estates where laptops, jump hosts, developer workstations, and managed servers can all introduce hidden identity dependencies.
For a governance baseline, device-based discovery should be considered alongside the NIST Cybersecurity Framework 2.0 visibility and asset-management concepts, then extended with identity-specific analysis from Ultimate Guide to NHIs — Key Challenges and Risks and the Top 10 NHI Issues. The most common misapplication is assuming SaaS discovery alone is complete, which occurs when local executables and endpoint automation are never inspected.
Examples and Use Cases
Implementing device-based discovery rigorously often introduces operational overhead, requiring organisations to weigh better visibility against endpoint agent maintenance, privacy review, and inventory reconciliation costs.
- A security team scans developer laptops to find locally installed scripts that authenticate to production APIs using embedded tokens.
- A workstation management platform inventories installed automation tools so hidden service accounts can be mapped to owners and offboarding workflows.
- An incident responder inspects a compromised server to identify unauthorised software that may have created or reused secrets outside approved managers.
- A cloud governance team correlates endpoint findings with browser and SaaS data to reveal applications that never appear in network-based discovery.
- An organisation uses device-based discovery to support NHI Lifecycle Management Guide controls when endpoint-hosted automation needs inventory, ownership, and retirement tracking.
In practice, this approach complements external guidance such as NIST Cybersecurity Framework 2.0 by making asset discovery more complete at the endpoint layer, where local applications often create identity risk before central platforms can observe it.
Why It Matters in NHI Security
Device-based discovery matters because many NHI failures start where central visibility ends. Local applications can create service principals, call protected APIs, cache long-lived secrets, or run automation under privileged accounts without ever appearing in the systems used for directory-only or SaaS-only oversight. That blind spot weakens secrets governance, makes ownership unclear, and delays offboarding when a device is lost, repurposed, or compromised.
The governance stakes are high. NHI Mgmt Group reports that only 5.7% of organisations have full visibility into their service accounts, and 80% of identity breaches involved compromised non-human identities such as service accounts and API keys. Device-based discovery helps close that gap by showing where identity-bearing software actually lives on endpoints, not just where it is supposed to be registered.
Used well, this practice supports Ultimate Guide to NHIs guidance on visibility and rotation and reinforces broader control objectives in NIST Cybersecurity Framework 2.0. Organisations typically encounter the urgency of device-based discovery only after a workstation compromise, at which point hidden applications and the identities they use become operationally unavoidable to address.
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 CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 | Device-based discovery improves visibility into hidden NHIs and local software. |
| NIST CSF 2.0 | ID.AM | Asset management requires knowing what software exists on endpoints. |
| NIST Zero Trust (SP 800-207) | Zero Trust depends on complete device and workload visibility before access decisions. |
Inventory endpoint-installed software and link each identity-bearing app to an owner and lifecycle record.
Related resources from NHI Mgmt Group
- What is the difference between network detection and identity-based discovery for AI agents?
- How do backup codes compare with device-based MFA for resilience?
- Why are identity-based attacks growing faster than traditional network attacks?
- Why is NHI discovery and inventory the primary goal of NHI security?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on June 9, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
