The best balance comes from user-centric controls that make secure use easier than insecure workarounds. Organisations should let employees register applications, automate password rotation and 2FA, track activity at the individual level, and remove access cleanly. That approach preserves productivity while giving security teams the oversight needed for compliance.
Why This Matters for Security Teams
Employee application choice is rarely a simple convenience issue. When staff can adopt the tools that fit their workflow, they usually move faster and shadow IT pressure drops. The security challenge is that every approved app becomes a potential data path, identity surface, and compliance obligation. Modern governance has to reconcile user adoption with auditability, access control, and lifecycle management.
That balance is consistent with the control intent behind NIST Cybersecurity Framework 2.0, which emphasises governance, asset visibility, and risk-based protection rather than blanket prohibition. It also aligns with NHIMG guidance on Top 10 NHI Issues, especially where applications create connected identities, delegated access, and persistent tokens that outlive the user’s original need. In practice, many security teams discover the real risk only after a productivity-approved app has already accumulated broad access, weak monitoring, and unrevoked permissions.
How It Works in Practice
The best model is not “approve everything” or “approve nothing.” It is controlled choice. Organisations maintain an approved application catalogue, but allow employees to request tools when there is a business need. Security teams then evaluate the application’s data handling, authentication method, logging, vendor posture, and exit process before it is exposed more broadly.
Once approved, access should be tied to identity and lifecycle controls rather than informal sharing. That means centralised SSO where possible, automated password rotation for any credentials that remain, mandatory 2FA, and individual-level activity logging so usage can be attributed to a person, not just a shared app account. Where the application supports it, short-lived tokens and scoped access are preferable to long-lived secrets. For governing the broader lifecycle, NHIMG’s Lifecycle Processes for Managing NHIs is the right lens because every app registration creates an identity relationship that must be provisioned, monitored, reviewed, and removed.
Operationally, teams should define:
- who can request apps and who approves them
- what data classes the app may access
- what logs must be retained for audit and investigation
- how tokens, passwords, and account links are rotated or revoked
- how offboarding removes access cleanly across business and SaaS systems
This works best when combined with inventory and review discipline. Without it, “employee choice” turns into unmanaged sprawl, especially where business units add apps outside procurement or when SaaS integrations create hidden delegated access that security teams never see until an incident or audit exposes it.
Common Variations and Edge Cases
Tighter application control often increases friction, so organisations have to balance speed against review depth. That tradeoff is especially visible in teams that rely on niche SaaS tools, contractors, or cross-border operations where legal, privacy, and procurement requirements differ by region.
Best practice is evolving for applications that use OAuth grants, API connectors, or embedded AI features. There is no universal standard for this yet, but current guidance suggests treating these connections as active identity relationships, not passive software installs. That means reviewing consent scopes, monitoring token age, and revoking access when the business need ends. The security concern is not only the application itself, but also what it can reach through delegated permissions. NHIMG’s 2024 ESG Report: Managing Non-Human Identities shows how quickly connected identities become a governance problem when rotation and monitoring are weak.
Another edge case is bring-your-own-app environments, where productivity teams may use tools that never appear in the central stack. In those environments, security policy should focus on minimum acceptable controls, not a rigid whitelist. If the organisation cannot monitor the app, cannot revoke access, or cannot evidence who used it, then it does not meet compliance expectations even if it helps productivity.
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 CSA MAESTRO address the attack and risk surface, while NIST CSF 2.0, NIST SP 800-63 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 | Employee-approved apps often create connected non-human identities and tokens. |
| NIST CSF 2.0 | PR.AC-1 | Balances user access with managed, authenticated application approval. |
| NIST SP 800-63 | AAL2 | Strong authentication supports safer employee app access without shared credentials. |
| NIST AI RMF | Risk governance is needed when user choice expands the application attack surface. | |
| CSA MAESTRO | GOV-04 | Agent and app governance needs lifecycle controls and policy enforcement. |
Assess app choice through governance, map risks, and document accountability for each approved tool.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on August 27, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
