Just got the pitch from our rep about the new Identity Management module for Umbrella. They're pushing it hard as the next big thing for securing access, especially with remote work.
I've looked at the feature list. It gives you tighter integration with your IdP, more granular policies based on user identity, and supposedly better visibility into shadow IT. But the licensing cost isn't trivial—it's a noticeable bump on top of our existing DNS-layer and SIG licenses.
My main question is about real-world value versus cost. For those who have rolled it out:
* What tangible security gaps did it actually close that DNS policies or your existing IdP couldn't?
* Are the reporting and alerting features actionable, or just more noise?
* How does the operational overhead compare? Does it simplify management or add another complex layer?
Trying to decide if this is a genuine force multiplier for security or just another checkbox feature. Our team is lean, so anything that adds complexity needs to pay for itself in reduced risk or admin time.
cb
I run security for a ~800 seat SaaS shop. We have the full Umbrella stack (DNS, SIG) plus Palo Alto Prisma Access. We piloted the Identity module for six months, then dropped it.
* **Target Audience:** Enterprise orgs with chaotic, BYOD-heavy remote work. If you already have a locked-down VPN/VDI setup and a mature IdP, the gap it closes is narrow.
* **Real Cost:** The quoted price was an extra ~$3-4 per user per month on top of our existing Umbrella commit. The real cost was the engineering time to debug IdP sync quirks.
* **Integration Effort:** Took about two weeks of back-and-forth with our Okta team to get user groups syncing correctly for policy application. The logs were a nightmare to parse at first.
* **Clear Win:** Blocking specific shadow IT apps by user, not just IP. We could finally stop Salesforce for the marketing team but allow it for sales. That was the one actionable feature.
* **Where It Breaks:** It doesn't replace your IdP's conditional access rules. It's another policy layer. If your IdP is already doing device trust/geo-blocking, this adds complexity, not clarity.
My pick: Skip it unless you have a clear, unsolved problem of app-by-app user-level blocking *outside* your VPN. For us, Prisma handled that. If you're all-in on Umbrella and your IdP policies are basic, maybe it's worth the $3/user. Tell me your VPN setup and how granular your Okta/Azure AD policies are now.
show the math
Your lean team concern is the critical factor. The module's value is almost entirely in tying DNS-layer blocks to user identity. That's a powerful control, but only if you lack a simpler way to enforce it.
DNS policies work on IP. If your users are behind a corporate VPN or a SIG tunnel with a predictable egress IP, you can already map traffic to user groups via your firewall logs and have your IdP handle app-specific conditional access. The Umbrella module becomes another policy translation layer to maintain.
The reporting is only actionable if your current visibility stops at the IP level. If you can already answer "who accessed this risky domain," the new alerts are just a different dashboard. It simplifies management only if it replaces a more cumbersome toolchain; it adds complexity if it's a net-new system.
—J
Great question. Our team is also lean and trying to figure this out. You hit on my exact worry about adding complexity without clear payoff.
From what I've read, user400's point about it being a good fit for chaotic, BYOD setups makes sense. But if everyone's on a managed device with your VPN, maybe the gap isn't as big as the sales pitch says. The operational overhead from debugging sync issues sounds rough.
I'm curious about the "simplify management" part too. Does it actually give you a single dashboard that's easier, or is it just another system you have to check? If you already have good logs tying IPs to users, maybe it's more noise.
You've zeroed in on the key operational question. The "simplify management" claim hinges on the assumption that your current process for mapping IPs to users is manual or slow. If you have a mature SIEM ingesting both your IdP logs and firewall/proxy egress logs, you've already built that correlation engine. The module just gives you a pre-built version.
Where it *can* simplify is in policy creation. Writing a single rule like "Block category:High-Risk for userGroup:Contractors" is faster than maintaining that logic across your IdP's conditional access policies *and* your firewall's DNS rules. But you pay for that convenience with the new integration surface area user400 mentioned.
So the real question becomes: how often are you creating or modifying these user-contextual DNS policies? If it's a set-and-forget control for a few high-risk groups, the overhead of the module likely outweighs the occasional manual lookup.
Data is the new oil – but only if refined