The Identify function is the part of NIST CSF 2.0 that focuses on understanding what must be protected. It covers asset inventory, business context, risk assessment, and review of changes in systems and processes so teams can locate entry points and prioritize controls based on actual exposure.
Expanded Definition
The Identify function in NIST Cybersecurity Framework 2.0 establishes the organisational picture of what exists, what matters, and what exposure follows from each system, process, and identity dependency. In NHI security, that means more than listing servers and applications. It includes service accounts, API keys, machine identities, secrets repositories, CI/CD integrations, and the business services they enable. Used well, Identify connects asset inventory to risk prioritisation so controls are applied where compromise would cause the greatest operational impact.
That distinction matters because NHI risk is often invisible until a deployment, integration, or ownership change reveals it. The function is closely associated with asset management, governance, and risk analysis in the NIST Cybersecurity Framework 2.0, but its application to NHIs is still evolving across vendors and internal operating models. Some teams treat it as a one-time inventory exercise; in practice, it must reflect change over time, including new integrations, rotated credentials, and deprecated workflows. The most common misapplication is treating Identify as a static asset list, which occurs when teams ignore non-human identities embedded in code, pipelines, and third-party workflows.
Examples and Use Cases
Implementing Identify rigorously often introduces inventory and ownership overhead, requiring organisations to weigh better risk visibility against the effort of continuous classification and review.
- Mapping every service account to a business service so owners can determine whether a failure would affect production, billing, or customer data.
- Tracking secrets stored in source code and build pipelines, then classifying them by sensitivity and reachable blast radius.
- Reviewing newly added integrations after release changes so dormant machine identities do not remain unassessed.
- Documenting third-party access paths used by automation tools to ensure exposure is visible before a compromise occurs.
- Using findings from incidents such as JetBrains GitHub plugin token exposure and Hard-Coded Secrets in VSCode Extensions to improve how teams discover hidden secrets in developer tooling.
For deeper context on how identity exposure appears in real-world software supply chains, NHI Management Group research such as Code Formatting Tools Credential Leaks helps show why inventory must include tooling, not just production systems.
Why It Matters in NHI Security
Identify is the starting point for every defensible NHI control decision because unknown identities cannot be governed, monitored, or revoked with confidence. Without a complete understanding of where NHIs exist and what they can reach, organisations tend to overgrant access, miss orphaned credentials, and understate blast radius. That is especially dangerous in environments where automation creates and uses identities faster than security teams can review them.
NHIMG research shows that only 5.7% of organisations have full visibility into their service accounts, while 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface. Those numbers illustrate why Identify is not an administrative formality. It is the prerequisite for meaningful least privilege, segmentation, and response planning.
Organisations typically encounter the cost of poor identification only after a breach, an audit finding, or a failed offboarding event, at which point the Identify function 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 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | ID.AM-1 | Asset inventory is central to Identify and includes NHI assets, not just traditional IT. |
| OWASP Non-Human Identity Top 10 | NHI-01 | Visibility gaps and undiscovered NHIs are core identity governance failures. |
Inventory NHIs, secrets, and dependent services continuously so exposure can be assessed accurately.
Related resources from NHI Mgmt Group
- What is the difference between function calling and MCP for enterprise security?
- When does MCP make more sense than function calling?
- What is the difference between application RBAC and function-level permissions for MCP?
- Why do unsalted password hashes remain risky even when the hash function is strong?
