A device inventory identifies where systems are located. A privilege inventory reveals where an attacker could gain administrative access.
An endpoint record may confirm that a machine exists, identify its owner, and indicate whether a management agent has recently communicated with the platform. However, that record does not reveal who has administrative rights on the machine.
This difference is important because an attacker does not require a complete inventory of every asset. A single valid privileged path to a valuable endpoint can be sufficient. When known devices are reported as proof that privileged account discovery has been completed, the wrong security condition is being measured.
A device inventory identifies known systems. Privileged account discovery identifies which identities have administrative access to those systems, how that access is assigned, whether the evidence is up to date, and which endpoints still lack a successful scan. Successful scan coverage should therefore be measured against the entire in-scope endpoint population. Direct and group-derived administrative access can then be analyzed separately. Device coverage should not be presented as equivalent to privilege visibility.
Device inventory and privilege discovery answer different questions
Device inventory remains essential, but its purpose is primarily asset management: determining which systems are known to the organization. A device inventory entry can include details such as the hostname, assigned owner, operating system, business unit, installed management agent, and latest check-in time.
Privileged account discovery addresses a separate security question: which identities currently have the ability to administer each system, and through what access relationship?
| Device inventory can show | Privilege inventory must show |
| The endpoint is known to exist | The endpoint’s privilege state was successfully examined |
| The endpoint has an assigned owner or management agent | Which accounts and groups hold administrative access |
| The endpoint has a recorded last check-in time | When the privilege information was collected |
| The endpoint is associated with a business unit | Whether administrative access is assigned directly or inherited through group membership |
| The endpoint is included within the management scope | Which in-scope endpoints still lack a trustworthy discovery result |
A device can therefore appear in inventory while the membership of its local Administrators group remains unknown.
The device list should be treated as the initial population for discovery rather than as the discovery result itself. Until a privilege check completes successfully, the endpoint should remain classified as part of the coverage gap.
Privileged account discovery needs a coverage denominator
Every privilege-related metric requires a clearly defined denominator. For endpoint discovery, one practical starting metric is:
Current privilege coverage = in-scope endpoints with a successful, current privilege scan / all in-scope endpoints
The definition of “current” should be established separately for each endpoint population. A seven-day-old result might be acceptable for workstations while being too old for critical servers. The accepted interval should reflect how quickly administrative access can change within each environment.
The denominator should not decrease simply because some systems are difficult to scan. At minimum, the following categories should remain visible:
- Successfully scanned within the accepted interval
- Successfully scanned previously, but now outside the accepted interval
- Offline or unreachable
- Failed because of authentication, authorization, network connectivity, or configuration problems
- Known endpoints that have never been scanned
- Newly discovered device records that have not yet been reconciled with a scan target
Each category represents a security condition requiring attention. An offline, failed, or never-scanned endpoint may still have persistent administrative access and should not be considered clean.
Enrollment and health information indicate the operational state of a device. Privilege coverage provides current evidence of which identities hold administrative access.
Effective administrative access must be traced back to the endpoint
For a Windows endpoint, the local Administrators group is the practical place to begin. Its members may include a local account, a specific domain account, or a domain group. Effective administrative access may also include identities that gain privileges through group membership.
This creates two distinct views:
- Direct membership: An individual account or group is listed directly in the endpoint’s local Administrators group.
- Group-derived access: A user or account receives administrative privileges by belonging to a group that is itself a direct or nested member.
Direct assignments describe how the endpoint itself is configured. Resolving group-derived relationships reveals how far an identity can reach across the environment. Reviewing only the entries listed directly in local groups can therefore understate the true scope of administrative access.
Local accounts also require particular attention. MITRE ATT&CK T1078.003, Local Accounts, describes how attackers can misuse valid local credentials for persistence, privilege escalation, defense evasion, and system access. MITRE also states that reusing local account credentials across multiple systems can facilitate lateral movement. A standard device inventory cannot determine whether the same local administrative identity or recurring credential pattern creates such reach.
Privilege discovery must therefore connect evidence collected from endpoints with the identity relationships that make administrative access effective.
Endpoint platforms extend discovery; business context guides policy
Asset-management and endpoint platforms help establish the population that falls within scope. Where integrations are available, their collection mechanisms can also extend evidence gathering across managed endpoints.
Reliable discovery results associate the outcome and timestamp of every check with the administrative relationships detected during that check.
Business context converts this technical evidence into policy decisions. Discovery information can be combined with account ownership, operational dependencies, and legitimate business requirements to determine which administrative relationships should be retained, reviewed, or removed.
These responsibilities complement one another:
- Asset-management and endpoint platforms establish scope and, where integrations exist, expand collection capabilities.
- Privileged account discovery identifies administrative relationships and assesses how complete the discovery coverage is.
- Ownership information, dependency data, and policy requirements provide the context needed for remediation.
Measure visibility before measuring privilege reduction
Privilege counts become meaningful only after discovery coverage has reached a stable level
When scanning expands into an additional server segment, the total number of detected privileged relationships may initially increase. This increase can result from better visibility rather than greater exposure. Coverage and exposure should therefore be tracked together so that later decreases represent access that was actually removed rather than evidence that simply disappeared.
This remains a common operational problem. The Netwrix 2026 Data and Identity Security Report found that 76% of organizations are unable to revoke standing access immediately after it is no longer required. Effective revocation begins with precise knowledge of where that access exists and whether the evidence describing it is still current.
Visibility and exposure should be reported together. Useful measurements include:
- Total number of in-scope endpoints.
- Number and percentage of endpoints with a successful and current privilege scan.
- Number of out-of-date, failed, offline, never-scanned, and unresolved endpoints.
- Identities with direct or group-derived local administrator access.
- The number of endpoints each identity can administer.
- The age of the oldest result that is still classified as current.
After coverage becomes stable, attention can shift toward identities with broad administrative reach, repeated local accounts, unexpected group relationships, and privileged access to critical systems. At that stage, a reduction in the number of privileged relationships can serve as evidence that remediation has taken place.
How NPS-D turns device records into privilege evidence
Netwrix Privilege Secure for Discovery (NPS-D) is a module of Netwrix Privilege Secure converts endpoint inventory information into actionable evidence about privileged access. It discovers local administrative access across managed Windows endpoints, records both direct and group-derived administrator relationships, and distinguishes scan status from the mere existence of a device record. As a result, security teams gain visibility into both discovered privileges and the coverage status supporting those findings.
NPS-D can gather privilege information directly from Windows endpoints by using a valid Scan account, without requiring an NPS-D agent to be installed on each endpoint. It combines directory information from Active Directory, Microsoft Entra ID, or both with local administrator evidence collected through direct network connectivity or through a supported EDR integration such as Tanium Cloud. This approach extends discovery to endpoints that are either directly reachable or managed through an integrated EDR platform.
In environments using Microsoft Intune, the managed-device inventory can help define the endpoint population. When Intune information is reviewed together with NPS-D privilege evidence, it becomes possible to distinguish which endpoints are under management, which identities can administer them, how that access is assigned, and when the supporting evidence was collected.
NPS-D links individual endpoint findings to identities. This enables analysis of how widely a privileged identity can reach across systems while distinguishing direct assignments from group-derived access and preserving visibility into remaining coverage gaps.
A practical NPS-D workflow consists of the following steps:
- Define the endpoint population that falls within scope.
- Collect current evidence of local administrator access and calculate discovery coverage.
- Trace direct and group-derived administrative relationships back to the corresponding identities.
- Review ownership, operational dependencies, and approved exceptions.
- Progress from visibility to policy enforcement through controlled stages.
After legitimate administrative requirements have been established, NPS-D can also support the reduction of unnecessary privileges. Enforcement can begin with a limited endpoint group, followed by a review of the results and a gradual expansion to additional systems.
Report privilege coverage
A trustworthy privilege inventory links four elements: an endpoint that belongs to the defined scope, a successful and current privilege scan, the administrative relationships discovered on that endpoint, and the identities that obtain effective access through those relationships.
Four practical actions can establish this foundation:
- Define the complete endpoint population that is within scope.
- Separate devices that are merely known from endpoints that have a successful and current privilege scan.
- Investigate every record that is out of date, failed, offline, never scanned, or unresolved.
- Prioritize direct and group-derived administrator relationships according to their reach and business importance.
An environment in which every device can be listed, but administrative access, evidence age, and unseen systems cannot be identified, has a device inventory. It does not yet have complete privileged account discovery.
