A consumer installation is a third-party application or integration connected to a platform to exchange data or trigger actions. It becomes an identity governance issue when its permissions are broad, its owner is unclear, or its access is never reviewed after initial approval.
Expanded Definition
A consumer installation is more than a convenience feature. In NHI governance, it is any third-party app, bot, or integration granted access to data, events, or actions inside a platform, and therefore it behaves like a non-human identity with standing permissions. Definitions vary across vendors, but the governance question is consistent: who approved it, what can it do, and when will its access be reviewed?
The term is often used loosely across SaaS, collaboration tools, and AI-enabled workflows, yet the security impact depends on the same core controls used for other NHIs: inventory, scope, owner assignment, secret handling, and revocation. That is why the Ultimate Guide to NHIs treats third-party exposure, lifecycle management, and visibility as central governance concerns, while NIST Cybersecurity Framework 2.0 places access control and ongoing monitoring inside a broader risk program.
The most common misapplication is treating a consumer installation as a one-time user choice, which occurs when broad OAuth scopes or API permissions remain active after the original business need has changed.
Examples and Use Cases
Implementing consumer-installation controls rigorously often introduces friction for end users and administrators, requiring organisations to weigh productivity gains against the overhead of review, approval, and periodic revalidation.
- A project management app requests read access to calendars, files, and messaging channels. The integration may be useful, but governance must confirm the owner, the exact scopes, and whether the platform can revoke access cleanly.
- A customer support bot is installed to open tickets automatically and retrieve account details. Once it can trigger actions, it should be treated as an NHI with bounded privileges, not just a “plugin.”
- A marketing automation tool connects to a CRM and syncs contact data. If no one owns the installation after procurement, access can persist long after the vendor relationship or campaign ends.
- An AI assistant embedded in a collaboration suite uses delegated permissions to summarize documents and post updates. That workflow may improve speed, but it also expands the blast radius if tokens are over-scoped or leaked.
In practice, this category overlaps with OAuth app governance, third-party risk review, and NHI lifecycle management. The most mature teams align review cadence to the platform’s privilege model and to the broader control expectations described in Ultimate Guide to NHIs and NIST Cybersecurity Framework 2.0.
Why It Matters in NHI Security
Consumer installations matter because they often become invisible NHIs: approved once, then forgotten, while retaining access to sensitive data and actions. That pattern is especially dangerous when consent screens are broad, ownership is unclear, or secrets and refresh tokens are stored outside managed controls. NHIMG research shows that 92% of organisations expose NHIs to third parties, a reminder that external integrations are now part of the attack surface, not an edge case. The same guide also highlights how visibility and offboarding gaps leave organisations unable to answer basic questions about what is connected and who can remove it.
For practitioners, the key issue is not whether an installation is “useful,” but whether it has a documented business purpose, an accountable owner, and a retirement path. That is why NHI governance should include periodic access review, scope minimisation, and revocation testing, consistent with the monitoring and access control expectations in Ultimate Guide to NHIs and the risk-management posture in NIST Cybersecurity Framework 2.0.
Organisations typically encounter consumer-installation risk only after a breach review, token theft, or an audit uncovers stale third-party access, at which point the installation 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-02 | Covers secret handling and over-privileged non-human access. |
| NIST CSF 2.0 | PR.AC-4 | Addresses access permissions and least-privilege governance. |
| NIST Zero Trust (SP 800-207) | AC-4 | Zero Trust requires continuous verification of third-party access paths. |
Treat each installation as untrusted until its access is explicitly verified and constrained.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on June 6, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
