Application choice is the practice of employees selecting the productivity or efficiency tools they prefer for work. In practice, it shifts decision-making from IT to users, which can improve autonomy and productivity but also creates governance challenges when selected tools fall outside standard security controls.
Expanded Definition
Application choice describes a governance model in which end users select the productivity or efficiency tools they want for work, rather than relying on a centrally approved stack. It is often associated with employee autonomy, faster adoption, and better fit for specialised workflows, but in NHI security terms it also widens the control boundary because each chosen application may introduce its own service accounts, API keys, OAuth grants, certificates, and secrets handling patterns.
The term sits between shadow IT and sanctioned SaaS usage. Not every case of application choice is inherently risky, and the definition varies across vendors when they frame it as a digital employee-experience strategy. For NHI and IAM practitioners, the important question is whether the chosen application can be governed with approved identity lifecycle, access review, logging, and rotation controls. That usually means evaluating how the app authenticates, where secrets are stored, whether least privilege is enforceable, and how offboarding is handled when a user leaves or changes role. The NIST Cybersecurity Framework 2.0 helps anchor this discussion in risk management and control ownership rather than preference alone.
The most common misapplication is treating application choice as harmless because the buyer is a user, which occurs when teams overlook the NHI footprint and security obligations created by the selected tool.
Examples and Use Cases
Implementing application choice rigorously often introduces a tradeoff between user flexibility and the operational burden of keeping every approved tool inside policy, logging, and identity governance boundaries.
- A marketing team adopts a collaboration app with its own automation bot, which requires review of token scopes, secret storage, and revocation procedures before the app is allowed in production workflows.
- A data analyst chooses a reporting tool that integrates with cloud storage through service credentials, making it necessary to inventory the resulting NHI and align it with lifecycle controls described in the Ultimate Guide to NHIs.
- An engineering team prefers a low-code platform for internal dashboards, but security insists on validating how it handles secrets, which is where the NIST Cybersecurity Framework 2.0 becomes useful for control mapping and ownership decisions.
- A finance group requests a specialised planning app, and IT approves it only after confirming that access reviews, logging, and offboarding can be performed when the account owner changes.
- A research team uses a vendor AI assistant that connects to internal systems, prompting scrutiny of third-party access paths and NHI exposure before the tool is accepted for enterprise use.
Application choice is most defensible when the organisation can standardise intake reviews while still allowing users to select tools that meet a baseline security profile.
Why It Matters in NHI Security
Application choice matters because every user-selected tool can expand the non-human identity surface area, especially when the app creates tokens, bot accounts, machine credentials, or embedded secrets that security teams never see. That hidden layer is where governance failures accumulate: orphaned access, overbroad scopes, secrets stored in code or browser plugins, and poor offboarding. NHIMG research shows the scale of the problem, including that 96% of organisations store secrets outside of secrets managers in vulnerable locations and 97% of NHIs carry excessive privileges, which makes discretionary app adoption a direct security concern rather than a convenience issue.
For practitioners, the risk is not simply that a tool is unapproved. The deeper issue is that application choice can bypass procurement, architecture review, and identity lifecycle controls unless there is an explicit intake process. The Ultimate Guide to NHIs is useful here because it frames visibility, rotation, and offboarding as operational necessities, not optional hygiene. Organisational leaders also use the NIST Cybersecurity Framework 2.0 to connect this issue to risk governance, asset visibility, and access control expectations. Organisations typically encounter the real cost only after a tool is decommissioned or an employee departs, at which point application choice 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 and OWASP Agentic AI Top 10 address the attack and risk surface, while NIST CSF 2.0, NIST Zero Trust (SP 800-207) and NIST SP 800-63 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 | User-chosen apps often create unmanaged secrets and tokens. |
| NIST CSF 2.0 | ID.AM-1 | Application choice expands the asset inventory and governance scope. |
| NIST Zero Trust (SP 800-207) | Chosen apps must still be authorized continuously under zero trust. | |
| NIST SP 800-63 | AAL2 | Apps relying on delegated access need appropriate identity assurance. |
| OWASP Agentic AI Top 10 | A1 | Chosen AI tools can introduce autonomous actions and tool access risks. |
Inventory app-generated NHIs and enforce secret storage, rotation, and revocation before approval.
Related resources from NHI Mgmt Group
- How do organisations balance employee application choice with security and compliance requirements?
- How should security teams balance Zero Trust controls with employee application choice in the workplace?
- Why do application testing tools matter for NHI governance?
- Where should practitioners go deeper on agentic application risks?
