A primary entity is the starting record type for a report or query. It defines the main dataset that other objects are joined to, such as users, devices, or applications. Choosing the right anchor is critical because it shapes the scope, accuracy, and usefulness of the resulting compliance or investigation report.
Expanded Definition
A primary entity is the anchor record in a query, report, or investigation. In NHI security, it is the object other datasets are joined to, such as a service account, workload, API key holder, device, application, or host. The choice of primary entity determines what is treated as the core subject and what is treated as supporting context.
This concept matters because the same event can produce very different outcomes depending on whether the anchor is a user, a machine identity, or an application instance. That distinction is central to inventory, detection engineering, compliance reporting, and incident reconstruction. Usage in the industry is still evolving, and different tools may label the anchor as the primary entity, subject, asset, or root object. In practice, the term should be interpreted as the operational starting point for analysis, not as a fixed identity category. For broader NHI governance context, the Ultimate Guide to NHIs is the most relevant NHIMG reference, while NIST Cybersecurity Framework 2.0 provides a useful control-oriented lens for structuring the data around that anchor. The most common misapplication is treating the primary entity as whatever object is easiest to query, which occurs when teams optimize for schema convenience instead of investigative accuracy.
Examples and Use Cases
Implementing primary entity selection rigorously often introduces modeling overhead, requiring organisations to weigh cleaner analysis against slower report design.
- In a service account audit, the primary entity may be the service account itself, with token issuance, privilege grants, and rotation history joined as supporting evidence.
- In a workload investigation, the primary entity may be the application instance, while its container image, runtime host, and outbound secrets access provide context for compromise analysis.
- In compliance reporting, a device can be the primary entity when the report must prove configuration state, authentication events, and policy enforcement for that endpoint.
- In an access review, a human user may be the anchor for one report, but the same dataset may need the application or API client as the anchor when looking at delegated machine access.
- When building a dashboard from identity telemetry, teams often use the anchor to ensure Ultimate Guide to NHIs style inventory data is joined consistently to event logs and entitlement sources.
These use cases are typically governed by reporting intent rather than by a universal identity standard, so the anchor must be chosen to match the question being asked. A NIST Cybersecurity Framework 2.0 approach helps keep that choice tied to governance outcomes instead of ad hoc data extraction.
Why It Matters in NHI Security
Primary entity selection affects whether an NHI report is operationally trustworthy. If the anchor is wrong, entitlement drift, secret exposure, and privilege escalation can be hidden behind incomplete joins or misleading rollups. That becomes especially dangerous in environments where NHIs outnumber human identities by 25x to 50x, because the analysis surface is already large and easy to fragment. NHIMG reports that only 5.7% of organisations have full visibility into their service accounts, which means anchor selection often determines whether a team sees the identity that matters or only a partial proxy.
For NHI governance, the anchor should support traceability from the identity outward to its credentials, permissions, workloads, and dependencies. That is essential for rotation, offboarding, and incident response, especially when third-party exposure or dormant credentials are part of the risk picture. The Ultimate Guide to NHIs is particularly useful when defining that traceability, because it frames why inventory and lifecycle controls fail when the underlying record model is inconsistent. Organisations typically encounter reporting gaps only after an investigation cannot reconstruct ownership or blast radius, at which point the primary entity becomes 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 | Primary entity choice affects which NHI is treated as the security subject in analysis. |
| NIST CSF 2.0 | GV.OV-01 | A primary entity supports consistent governance views of what is being monitored and reported. |
| NIST Zero Trust (SP 800-207) | SC-7 | Zero Trust decisions depend on identifying the exact subject whose access and context are evaluated. |
Anchor reports on the actual NHI subject so inventory, exposure, and remediation map to the correct identity.
