Strict blocking often pushes users to work around controls by turning off endpoint agents, bypassing proxies, or changing proxy settings. That creates shadow IT the security team cannot see and weakens relationships with employees. A better approach is to understand actual use, secure high-risk apps, and offer safer alternatives before removing access.
Why unsanctioned SaaS controls can backfire
unsanctioned saas becomes riskier when security tries to eliminate it only through hard blocking. Users who still need the capability often route around controls, which replaces visible, governable use with hidden access paths and makes the environment harder to monitor, investigate, and recover.
The core problem is that the control is targeting the symptom, not the behaviour. If the business need remains unmet, people will move to workarounds that are usually less observable and less controlled than the original app. That can create more exposure than the risky SaaS usage itself.
That dynamic is why control strategy matters as much as control intent. A complete response usually includes application discovery, risk-based allowlisting, safer alternatives, and tighter governance around high-risk apps rather than a simple deny rule.
What actually changes when users work around the block
When users bypass endpoint agents, proxy settings, or network filters, the security team loses the telemetry needed to distinguish benign business use from true shadow IT. The result is not just reduced enforcement, but reduced understanding of where data is going and which apps have become embedded in workflows.
Once a bypass becomes normalised, organisations can also inherit a larger trust problem. Employees learn that controls are negotiable, which weakens the credibility of future security changes and makes later enforcement harder to introduce cleanly.
Where the unsanctioned app handles logins, tokens, file sharing, or integrations, the risk compounds because hidden use often means hidden credentials and unknown third-party dependencies. A secure response should therefore focus on reducing the reasons to evade controls, not only the ability to evade them.
Risk and Threat Considerations
Strict blocking often increases operational and security risk because it drives usage into channels the organisation cannot see. The greatest exposure comes from losing visibility into data movement, authentication paths, and app-to-app connections, while users preserve the business workflow through informal workarounds.
Failure mechanism: Users bypass endpoint, proxy, or network controls, then continue using the SaaS app through unmanaged paths, which creates hidden data flows, unmanaged access, and weaker detection of misuse or compromise.
Impact: Security teams lose monitoring and response capability, shadow IT grows, and the organisation may end up with more exposed data and more brittle governance than if the app had been managed openly.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
CIS Controls v8, NIST CSF 2.0 and NIST SP 800-63 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS 1 — Enterprise Asset Inventory and Control | Unsanctioned SaaS control starts with knowing what is actually in use. |
| CIS 6 — Access Control Management | Blocking and bypass behavior are access-control problems with visibility consequences. | |
| CIS 8 — Audit Log Management | Hidden SaaS use removes the logs needed to detect misuse and investigate incidents. | |
| Recommendation — Inventory sanctioned and unsanctioned SaaS to scope shadow IT before enforcing restrictions. Apply access controls that reduce risky usage without pushing users into unmanaged bypass paths. Preserve audit visibility for SaaS traffic and admin actions so bypasses do not erase evidence. | ||
| NIST CSF 2.0 | ID.AM — Asset Management | Discovery of sanctioned and unsanctioned apps is essential to understanding exposure. |
| PR.AA — Identity Management, Authentication, and Access Control | The issue involves how users authenticate to and access SaaS applications. | |
| DE.CM — Security Continuous Monitoring | Bypassed controls reduce the organisation's ability to continuously monitor app use. | |
| Recommendation — Identify the SaaS estate and classify business-critical apps before deciding what to restrict. Enforce access governance that constrains risky apps while keeping authentication paths observable. Monitor for proxy bypass, endpoint tampering, and unexpected SaaS usage patterns. | ||
| NIST SP 800-63 | IAL — Identity Assurance Level | SaaS access often depends on how strongly users are authenticated and governed. |
| AAL — Authenticator Assurance Level | Bypass risk is amplified when weaker or hidden authentication paths remain available. | |
| Recommendation — Tie SaaS access decisions to the assurance level required for the data and workflow involved. Require stronger authentication for higher-risk SaaS access paths and monitor exceptions closely. | ||
Practitioner Guidance
What to verify: Confirm whether the blocked app is meeting a real workflow need, and identify which users, data types, and integrations depend on it. If the same users repeatedly find a way around the block, that is a signal to reassess the control design, not to keep tightening enforcement.
Decision rule: If an app is high-risk but widely used, prioritise visibility and containment first, then move to safer substitution or conditional access. If there is a lower-risk alternative that meets the same business need, make migration easier than bypass.
Common mistake: Treating all unsanctioned SaaS as equally removable. In practice, some apps are tolerated because they solve a real productivity problem, and the better security outcome is usually to bring them into a governed path rather than forcing them underground.
Practitioner takeaway: The goal is not to prove that blocking works, but to keep users inside a visible control plane where access, data handling, and escalation paths remain governable.
Related resources from NHI Mgmt Group
- Why do overly strict DLP controls often increase security risk instead of reducing it?
- Why does trying to block SaaS and AI usage often increase risk instead of reducing it?
- Why do cloud migrations often increase IAM risk instead of reducing it?
- Why do AD migrations often increase identity risk instead of reducing it?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 19, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
