Amar Jeer

Beyond DNS Filtering: Why Cisco Umbrella Can't Govern SaaS at the Tenant Level

June 3, 2026

MIN READ

Beyond DNS Filtering: Why Cisco Umbrella Can't Govern SaaS at the Tenant Level

Cisco Umbrella decides what to do with traffic by looking at a domain. That worked when the question was "is this site good or bad?" It does not work when the question is "is this the corporate Google Workspace, or the user's personal one?" DNS cannot tell the difference. The traffic goes to the same hostname either way.

That is the gap. And it is getting bigger every quarter as employees sign into SaaS apps with both personal and work accounts.

The 2-sentence answer

DNS-layer filtering like Cisco Umbrella resolves a hostname but cannot see which tenant (which Google Workspace, which Microsoft 365, which ChatGPT workspace) the user is logging into, so it cannot block personal accounts on the same domain as your corporate accounts. dope.security replaces Cisco Umbrella with an endpoint-based SWG that sees the full HTTPS request and uses Cloud Application Control to allow only your approved tenants, on every device, anywhere.

The DNS layer is blind to the tenant

Every SaaS app today serves multiple customers from the same set of public hostnames. chat.openai.com is the same domain whether a user is signing into your enterprise ChatGPT workspace or their personal account. drive.google.com is the same domain whether they are saving files to your corporate Drive or their personal Drive. login.microsoftonline.com is the same domain whether the credentials belong to your tenant or a free Hotmail address.

Cisco Umbrella sees the DNS lookup. That is it. The lookup is identical in both cases. The actual tenant identifier lives further up the stack, inside the HTTPS request, after the connection has been established and the user has typed an email and a password.

DNS cannot read encrypted traffic. DNS cannot read URLs. DNS cannot read tenant headers. It resolves a name to an IP and gets out of the way. So when an employee opens a tab to drive.google.com and signs into their personal Gmail to upload your customer list, Cisco Umbrella never had a chance to weigh in.

What tenant-level control actually means

Cloud Application Control (CAC) is the dope.security feature that closes this gap. The agent on the device inspects the HTTPS request, identifies the tenant the user is trying to authenticate against, and either allows it or blocks it based on policy. Your corporate ChatGPT tenant gets through. A personal ChatGPT account does not. Same domain. Same product. Two different outcomes.

The same logic applies to Google (allow only your workspace tenant), Microsoft 365 (allow only your verified domains), Claude, Slack, GitHub, and any SaaS app where personal and work accounts share infrastructure.

This is the layer Cisco Umbrella architecturally cannot reach. DNS filtering decides whether the user can resolve a hostname. It does not decide whether the user can sign in with the right identity. By the time the identity question matters, the DNS lookup is already long gone.

The three layers Cisco Umbrella misses

Tenant control is one piece of a broader visibility gap. An agent-based endpoint SWG sees three layers Cisco Umbrella's DNS-layer architecture cannot:

The URL path. Cisco Umbrella sees github.com. It does not see github.com/your-org/private-repo versus github.com/some-personal-fork. On-device SWG sees the full URL and can route policy accordingly.

The TLS-encrypted body. Cisco Umbrella sees the destination. It does not see what the user is uploading inside the TLS tunnel. On-device SWG decrypts and inspects locally, so it can run DLP, virus scanning, or AI-prompt classification on the actual content.

The application action. Cisco Umbrella sees "user reached drive.google.com." It does not see "user is exporting a 14 MB customer list to a personal Drive folder." On-device SWG sees the action because it sees the request body.

For modern SaaS use, the action and the tenant are where policy actually lives. The hostname is a starting point, not an answer.

The AI governance angle

This gap is even sharper for AI tools. ChatGPT, Claude, Gemini, and Copilot all serve enterprise tenants and personal accounts from the same domains. A DNS-layer block is binary: you either let everyone use chat.openai.com or you do not. There is no middle ground that says "yes for the corporate workspace, no for personal accounts."

dope.security's three-layer AI governance handles this directly. Shadow IT discovery surfaces who is using which AI tool, on which account. SWG policy decides which AI tools are allowed at all. Cloud Application Control decides which tenant of each allowed tool is permitted. Dopamine DLP then watches the prompts and uploads inside the allowed tenants so sensitive data does not leave with the answer.

You cannot replicate any of this on the DNS layer. The data Cisco Umbrella needs to make the decision is encrypted and ten layers above where DNS resolution happens.

What replacement looks like

Most teams replacing Cisco Umbrella are not trying to give up DNS filtering. They want to keep that hygiene layer and add what was missing: URL filtering, TLS inspection, on-device DLP, and tenant control. dope.security delivers all four through a single agent under 100 MB of RAM, pushed via Intune or Jamf, with policy that follows the user instead of the network. One reference point: Greylock Partners went from first proposal to signed contract in 27 days, replacing Cisco Umbrella for a distributed VC team where DNS-only filtering had stopped being enough. Another Cisco Umbrella customer migrated 2,000 machines to dope.security in two days.

The migration story is consistent. Teams keep their existing block list logic for as long as they want, point endpoints at dope.security in parallel, and watch the tenant-level visibility light up immediately. Personal Gmail uploads, unsanctioned ChatGPT logins, and Drive exports to personal accounts that DNS filtering had been silently letting through become visible and controllable on day one.

Where to go next

If you are evaluating Cisco Umbrella's renewal and the tenant control gap is biting, especially for AI tools, book a 20-minute demo of dope.SWG with Cloud Application Control. You will see the same DNS-layer filtering you have today, plus the four layers Cisco Umbrella architecturally cannot reach.

Try dope.security free or book a 20-minute demo at dope.security/demo.

The architecture choice in 2026

Most replacement evaluations end up comparing two architectures dressed in several vendor uniforms.

Architecture	Examples	HTTPS payload	Backhaul to vendor PoP	AI tool tenant control
Legacy cloud-proxy SWG	Forcepoint ONE, Zscaler ZIA, Netskope, Cisco Umbrella SIG, Symantec WSS	Yes (via PoP)	Yes	Partial
DNS-only filtering	Cisco Umbrella DNS, DNSFilter, TitanHQ, Cloudflare Gateway DNS	No	N/A	No
On-device SWG	dope.SWG	Yes (on endpoint)	No	Yes (out of the box)

Why the cloud-proxy lookalikes don't fix the architecture

Five structural facts every replacement buyer should weigh before signing with another cloud-proxy SSE vendor.

1. They are all cloud-proxy SWGs. Forcepoint ONE, Zscaler ZIA, Netskope Intelligent SSE, and Cisco Umbrella SIG all forward user traffic from the device to a vendor PoP, run inspection there, forward to the destination, then back. The data-plane architecture is the same; the marketing names differ. User-perceived performance is governed by PoP geography and capacity, not by anything the user controls.

2. The latency tax is per-request. Every page load, every API call, every SaaS interaction takes the PoP detour. Modern web pages chain dozens of HTTPS requests per render; the cost compounds. On a fiber-connected office user the round-trip is tolerable. On home wifi, hotel wifi, or international travel it isn't.

3. Renewal pricing tracks data center costs. Vendor infrastructure costs flow into renewal pricing. As power, cooling, and real estate costs rise, cloud-proxy SSE renewals climb with them. The macro trend applies regardless of vendor.

4. Geographic dead zones stay the same. China, sanctioned regions, and high-latency markets degrade the same way across all four vendors. Backhauling through the Great Firewall is brittle by design.

5. Trust transfer at decryption stays the same. Every cloud-proxy SWG decrypts your HTTPS payloads inside the vendor's data center. Audit and procurement teams in regulated industries face the same conversation with the new vendor as they did with the old one.

The migration playbook to dope.SWG

Six concrete cutover steps. Real-world deployments have finished in days, not months.

Step 1: Inventory current SWG scope. SWG, DLP, CASB, and DNS layer products, plus any heritage on-prem appliances, PAC files, IPsec tunnels, or GRE configurations. The SKU map drives both the capability comparison and the renewal math.

Step 2: Map AI governance asks across ChatGPT, Claude, Gemini, and Copilot. For each AI tool, decide: allow only the enterprise tenant (recommended), block entirely, or allow with prompt-content DLP. dope.SWG ships out-of-the-box Cloud Application Control for all four, plus Dopamine DLP on the prompt content itself.

Step 3: Scope endpoint DLP channels. AI prompts, SaaS uploads, copy-paste, file movement to personal cloud. Meet Dopamine DLP walks through the three modes (Block, Monitor, Off).

Step 4: Plan MDM rollout. dope.endpoint deploys via Intune, Jamf, Kandji, or any standard MDM tooling. Pilot first (a single team), then expand by department, then full fleet.

Step 5: Phase the cutover. Pilot in parallel with the incumbent SWG to validate policy behavior, then expand. Decommission the legacy agent and remove PAC files, IPsec tunnels, or GRE configurations from the network edge.

Step 6: Reclaim the renewal. One SKU at $60 per device per year replaces multi-product legacy SSE bundles. The renewal conversation gets shorter, the SKU count drops, and the spend usually drops with it.

Customer evidence

Real-world references where the on-device SWG architecture delivered the migration outcome.

Greylock Partners. Iconic Silicon Valley VC. Replaced Cisco Umbrella for dope.security. 27 days from first proposal to signed contract. Deployment via Intune in a phased rollout.

Outreach Health. Healthcare organization, 5k-10k employees, 34 offices in TX, AZ, and MA. Replaced a legacy SWG. 99% of devices secured within one week. 70% reduction in web access-related IT tickets in 90 days. Policy changes moved from days to minutes.

City of Visalia. 700+ user government workforce. Expanded coverage when employees went mobile and perimeter-based policies stopped following users off-network. On-device SSL decryption with no data center backhaul.

A VC firm. 2,000 machines migrated off Cisco Umbrella in two days. The architectural case at scale, on a hybrid fleet.

Fortune 100 deployment. 18,000+ devices secured. The architectural case at enterprise scale.

"The eval comparisons looked different across the legacy vendors until we drew the data-plane diagrams. They all collapsed into the same shape. On-device SWG was the only one where the diagram had no remote PoP in it. That was the moment we picked dope.security."
By a Security Architect, mid-market organization.

The non-technical reason it sticks

Architecture wins the eval, but support wins the rollout. dope.security's 24/7 white glove global support team is the reason migrations finish on schedule. Phased rollout questions land on a human, not a ticket queue. Mac kernel extension edge cases, Windows agent install quirks, MDM policy push timing, every one of those questions has been answered for someone else first. For a lean security org that's already stretched, that's not a soft benefit. It's the practical reason the cutover sticks.