What breaks when organisations depend on network blocking to control employee app choice?

Why This Matters for Security Teams

Network blocking looks decisive, but it rarely changes the underlying incentive structure that drives employee app choice. If a tool helps someone finish work faster, users often route around controls through personal devices, web variants, file-sharing links, or shadow IT. That leaves security teams with reduced visibility and a misleading signal that the risk has been contained when it has only been displaced.

This matters because application choice is usually an identity and governance problem, not a perimeter problem. NHI Management Group notes that only 5.7% of organisations have full visibility into their service accounts in the Ultimate Guide to NHIs — Standards, which is a useful reminder that access control gaps often persist even when the network is tightly filtered. When employees move work into unmanaged channels, the organisation also loses the authentication, provisioning, and logging signals needed to investigate misuse. The NIST model for trust shift makes the same point: NIST SP 800-207 Zero Trust Architecture assumes policy decisions must follow identity, device state, and context, not simply the network boundary. In practice, many security teams discover app sprawl only after data has already moved outside managed controls.

How It Works in Practice

Blocking by IP, domain, or firewall rule can suppress a specific app path, but it does not remove the business need that made the app attractive. If a sanctioned alternative is slower, harder to use, or missing features, employees look for the shortest path to completion. That is why current guidance suggests pairing control enforcement with identity-aware policy, sanctioned alternatives, and clear exception handling rather than relying on network denial alone.

The practical issue is that modern app use is often distributed across browsers, SaaS, mobile clients, and APIs. A blocked desktop application may still be reachable through a web interface, a consumer account, or a personal device on a different network. In that case, the security team has lost both visibility and governance, because the work is now happening outside enterprise authentication, device posture checks, and retention controls.

Security teams generally get better outcomes when they treat app choice as a managed access decision:

• Map the approved app set to business functions and data sensitivity.
• Use identity-based controls, SSO, conditional access, and device trust rather than only network filtering.
• Provide a fast exception process so users do not create shadow IT to meet deadlines.
• Monitor for unmanaged SaaS signups, personal account use, and data exfiltration paths.

This approach aligns with the operational view in Ultimate Guide to NHIs — Standards, which ties access to lifecycle management and visibility, not just connectivity. It also reflects the NIST SP 800-207 Zero Trust Architecture principle that access should be continuously evaluated at the point of use. These controls tend to break down when the organisation has no sanctioned alternative, because users will keep finding unmanaged routes that bypass the block.

Common Variations and Edge Cases

Tighter network blocking often increases operational friction, requiring organisations to balance containment against productivity and support burden. The tradeoff is especially visible in bring-your-own-device environments, remote work, and highly collaborative teams where users need rapid access to niche tools. In those settings, hard blocks can push activity into unmanaged browsers, personal accounts, or messaging apps, which makes the problem harder to govern rather than easier.

There is no universal standard for this yet, but current guidance suggests that the best control depends on the risk being managed. For commodity apps with low business value, blocking may be acceptable. For tools that support core workflows, a better pattern is approval, logging, and constrained access with explicit exceptions. That preserves visibility while reducing the incentive to bypass controls.

Another common edge case is third-party collaboration. If external partners depend on the same app, blocking it internally can create fragmented workflows and duplicate data movement. In those cases, security teams should focus on who can access what, from which device, and under what conditions, instead of assuming a network rule will eliminate use. The broader lesson from NHI Management Group research is that visibility and governance matter more than simple denial. Network blocking alone is most fragile when the organisation needs the tool enough that users are willing to work around it.

Related resources from NHI Mgmt Group

• What breaks when organisations depend on SSO as their only SaaS control?
• What breaks when organisations do not control prompt size, model choice, and context in AI systems?
• What breaks when organisations keep passwords as the default identity control?
• What breaks when organisations secure logins but ignore app approvals?