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

Why Network Blocking Fails as a Behaviour Control

Network blocking is a blunt control for a problem that is usually behavioural, not purely technical. If employees want a tool for speed, familiarity, or collaboration, they will often route around blocks through personal devices, mobile data, browser proxies, or shadow IT-style alternatives. That means the organisation may believe it has reduced exposure while the actual app choice has merely shifted into less visible and less governable channels. For security teams, that creates a mismatch between policy intent and operational reality, especially when the blocked app was never brought under approved authentication, logging, or provisioning. In practice, many security teams discover the control gap only after the unwanted tool has already become embedded in day-to-day work.

The issue is not that blocking never works technically. It is that blocking alone rarely changes the incentives that drive adoption, and it can encourage concealment rather than compliance. When that happens, the organisation loses the chance to apply measured control to the application lifecycle and instead gets an incomplete picture of where data and access are actually flowing. NIST SP 800-207 Zero Trust Architecture is useful here because it emphasises continuous verification and explicit access decisions rather than assuming the network boundary can carry the whole policy burden.

What Actually Happens in Day-to-Day Use

In practice, dependence on network blocking tends to fail in predictable ways. Employees do not usually stop at the first denied connection. They look for the easiest path to keep working, and that path often sits outside the corporate network path the block was designed to govern. A browser-based service may be replaced with a consumer clone, a desktop app may be replaced with a personal account, or the same app may be accessed from home or a phone where the block no longer applies. The control remains present, but its scope is narrower than the behaviour it is trying to shape.

• Users may switch to unmanaged endpoints that bypass corporate filtering.
• Shadow IT may increase because the policy blocks use but does not replace the business function.
• Security teams may lose telemetry when traffic moves to channels they do not monitor.
• Identity, provisioning, and retention controls may never be applied to the substituted tool.

The practical consequence is that the organisation often ends up governing the network path rather than the application itself. That is a poor fit when the real risk comes from data handled in the app, the accounts created around it, or the collaboration history that is now outside enterprise oversight. This approach breaks down most clearly when work can be completed through multiple access paths, because the block only constrains one of them.

When Blocking Creates Hidden Workarounds and Governance Gaps

Tighter blocking often increases user friction, requiring organisations to balance reduced access against the likelihood of hidden substitution. The control can still be useful for obvious high-risk destinations, but there is a genuine tradeoff: the harder the block, the more pressure there is to find an unmanaged route around it. Whether that is acceptable depends on whether the organisation is trying to prevent casual misuse or enforce a governed application standard.

This is also where guidance versus consensus matters. There is broad agreement that network controls are valuable for containment, but there is less consensus that they are effective as the primary method for influencing employee application choice. For application governance, the stronger pattern is to pair access restriction with identity-based approval, sanctioned alternatives, and visibility into what users actually adopt. If the organisation cannot observe the substitution path, then the block may reduce one risk while silently increasing another.

Another edge case is when the app is used for a legitimate business process but has an unsanctioned implementation. In that situation, a block can interrupt work without removing the underlying demand, so the business simply re-creates the same function elsewhere. That is why network blocking often becomes a temporary signal rather than a durable control.

Risk and Threat Considerations

The material risk is not just lost policy compliance. It is the creation of an unmanaged access path where corporate visibility, authentication standards, and retention controls no longer apply. Once employees shift to alternate channels, the organisation may also lose the ability to detect data exposure, account sprawl, or unsanctioned sharing.

Failure mechanism: The block is bypassed through another network, another device, or another application instance, so the control constrains transport rather than usage. That leaves the underlying business need intact while moving the activity into a less controlled environment.

Impact: Security teams lose reliable telemetry, remediation becomes harder, and sensitive work may continue through accounts or tools that were never provisioned, reviewed, or offboarded under normal governance.

Practitioner Guidance

What to prioritise: Treat network blocking as a containment measure, not as the primary way to manage employee app choice. The first question is whether the blocked tool is replacing a business function that people still need, because if it is, users will usually search for an equivalent channel.

What to verify: Verify where users actually complete the work after a block is introduced. If the activity reappears through personal devices, browser variants, or unsanctioned accounts, then the block has changed the path, not the behaviour.

Decision rule: If the goal is policy enforcement, pair the block with a governed alternative and visible access approval. If the goal is only to reduce obvious exposure, the block may still be useful, but it should be treated as a partial control with known bypass risk.

Practitioner takeaway: The most important judgement is whether the organisation is trying to stop use or govern use; network blocking can help with the first, but only broader control and visibility can sustain the second.

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 depend only on network enforcement for application security?
• What breaks when organisations keep passwords as the default identity control?