A user-generated NHI is a non-human identity created through normal employee activity, such as approving OAuth access, saving a token, or installing an application. It is often born outside central IAM workflows, which makes ownership, scope, and retirement harder to govern.
Expanded Definition
User-generated NHI describes a non-human identity that appears through ordinary employee behavior rather than an intentional IAM request, approval, and lifecycle process. In practice, it can be created when a user grants OAuth consent, installs a productivity app that receives API access, or saves a token outside a managed vault. The identity may be legitimate at creation, but its governance is often weak because ownership, purpose, and expiration were never formally assigned.
This matters because the term sits at the intersection of identity governance, application onboarding, and secret handling. In NHI Management Group terms, it is less about where the identity lives and more about how it came into existence and whether the organisation can still explain who approved it, what it can access, and when it should be removed. That distinction is increasingly important in environments governed by NIST Cybersecurity Framework 2.0, where access control and lifecycle accountability must be demonstrable.
Definitions vary across vendors on whether a user-generated NHI includes only OAuth grants or also locally created service accounts and ad hoc API tokens, so practitioners should document scope explicitly. The most common misapplication is treating these identities as harmless user productivity artifacts, which occurs when security teams only review centrally provisioned accounts and ignore shadow authorisations created during normal work.
Examples and Use Cases
Implementing control around user-generated NHI often introduces friction for employees, requiring organisations to balance convenient app adoption against the cost of tighter approval, monitoring, and revocation workflows.
- An employee approves a third-party SaaS app to read mailbox data, creating a persistent OAuth grant that becomes a user-generated NHI until it is reviewed or revoked.
- A developer saves a personal access token in a note-taking tool or chat platform, turning a simple convenience into an identity artifact that may outlive the original task.
- A business user installs a workflow app that can call internal APIs, and the resulting consent is never mapped to an owner in the IAM catalog.
- A contractor uses a browser extension that requests broad permissions, creating an access path that is visible only in the platform audit log, not in central onboarding records.
- In the Ultimate Guide to NHIs, NHIMG frames these identities as a lifecycle problem as much as an authentication problem, because they are often created outside formal workflows.
For governance teams, the practical use case is discovering where normal business activity has silently created durable machine access. That is also why identity discovery should be paired with platform telemetry and consent review, not just directory audits. The control challenge is similar to the access-review discipline described in NIST Cybersecurity Framework 2.0, but applied to identities that users themselves helped create.
Why It Matters in NHI Security
User-generated NHI is a high-risk category because it bypasses the usual guardrails that make identities explainable, reviewable, and removable. When these identities are created through everyday employee action, organisations often lack ownership records, rotation expectations, and clear retirement triggers. That creates blind spots in secret inventory, OAuth consent governance, and privileged access review. NHIMG research shows that 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, with 38% having no or low visibility and 47% only partial visibility, which is exactly the environment where user-generated NHI tends to proliferate.
That visibility gap matters because user-generated identities are often the first place over-broad permissions, duplicate secrets, and abandoned access accumulate. NHIMG’s Top 10 NHI Issues and the 52 NHI Breaches Analysis both reinforce a recurring pattern: identities created outside central workflows are harder to rotate, harder to revoke, and easier to forget. Once a user leaves, changes roles, or approves a risky integration, the identity can remain active without an obvious owner.
Organisations typically encounter the consequences only after an incident review, when an exposed token, excessive OAuth consent, or abandoned app access makes the hidden identity 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 | User-generated NHIs often evade formal creation and ownership controls. |
| NIST CSF 2.0 | PR.AA-1 | Identity proofing and access governance apply to machine access paths created by users. |
| NIST Zero Trust (SP 800-207) | Zero trust requires continuous verification of every identity, including user-created ones. |
Discover shadow-created NHIs and force ownership, approval, and expiry for every identity.
