Hey everyone! 👋 Wanted to share my team's experience after we made the switch from Umbrella to Cisco Secure Access (formerly Duo Beyond). We've been running it for about three months now, and the shift has been... significant.
For context, we're a mid-sized shop running a mix of on-prem and cloud-native apps. Umbrella was our DNS-layer security workhorse for years, but the move to a true Secure Service Edge (SSE) model with Secure Access was driven by our push towards zero-trust for all our dev and production environments.
**The Big Wins:**
* **Tighter Integration with Our CI/CD Identity:** Our devs use GitHub for everything. With Secure Access, we could tie application access directly to their GitHub SSO groups. No more managing IP allow-lists for SaaS tools like Vercel or internal dashboards. A new hire gets the right access on day one based on their team repo.
* **Infrastructure-as-Code Friendly:** The API and Terraform provider for Secure Access are miles ahead of what we had for Umbrella's more advanced features. Here's a snippet of how we now grant access to an internal monitoring portal:
```hcl
resource "cisco_sa_application" "grafana_internal" {
name = "prod-grafana"
host = "grafana.internal.example.com"
description = "Production Grafana Dashboard"
}
resource "cisco_sa_policy" "devops_access" {
name = "allow-devops-grafana"
application_ids = [cisco_sa_application.grafana_internal.id]
user_group_ids = [data.github_team.devops.id] # Linked via SCIM
allow_untrusted = false
}
```
* **The User Experience is Smoother:** The Duo/SSE client is less intrusive for the team than the old roaming client when accessing web apps. Fewer "why is this blocked?" tickets.
**The Gotchas & Migration Pain Points:**
* **It's a Different Beast:** Don't go in thinking it's just "Umbrella 2.0." It's a fundamental shift from network-layer control to application-layer identity. We had to re-map our policies entirely.
* **Cost Structure:** Be prepared for a different conversation with your rep. It's priced per user, which made sense for our SaaS-heavy use case, but required a thorough audit of who really needed "access" vs. just "DNS protection."
* **Logging & Monitoring:** The logs are powerful but different. We had to rebuild some of our Splunk dashboards and Grafana alerts to focus on user-to-application events instead of DNS queries.
Overall, we're happy with the move. It felt like upgrading from a really good lock on your front door (Umbrella) to a full-building keycard system where every room has its own permissions (Secure Access). The initial lift was real, but our developer experience and security posture for internal apps are much better for it.
Would love to hear if anyone else has gone through this migration and how you handled the policy translation. Any scripts or tools you found helpful?
Keep deploying!
Keep deploying!
I'm a platform lead at a 350-person fintech, managing our zero-trust migration across AWS EKS and on-prem VMware. We've run Umbrella SIG for remote user DNS and have had Secure Access in pilot for about six months for a subset of our internal applications.
The core differences from an operational perspective:
1. **Cost Model & Scale:** Umbrella's DNS and SIG components are relatively predictable per-seat or per-GB. Secure Access's true cost surfaces at the connector layer. Each lightweight connector node can handle ~1.2k-1.5k concurrent user sessions comfortably. For high-availability across two regions, we needed 4 nodes, which added about $1.2k/month to our commitment beyond the per-user license ($9-12/user/mo for the full SSE stack in our volume).
2. **Deployment & Agent Footprint:** Umbrella's roaming client is simple. Secure Access requires the 'Secure Client' (which includes AnyConnect). The transition for end-users is the biggest lift. You must migrate AnyConnect profiles and educate them on the new 'Application Portal' versus just having DNS filtering work transparently. The agent itself uses 50-70MB more RAM on average.
3. **Operational Visibility:** Umbrella's dashboards focus on DNS and IP layers. Secure Access's logs are far richer for application access (user X attempted to reach private app Y at this time), but aggregating them into our SIEM (Splunk) required a separate log forwarding setup and uses about 15% more ingestion volume due to the depth of context.
4. **Breakage Profile:** Umbrella could break obscure DNS resolution. Secure Access breaks application flows more directly if connector routing or identity provider sync is misconfigured. We had a 3-hour outage for an internal app because an Azure AD group rule for the Secure Access policy excluded a nested group we relied on. The policy evaluation is powerful but complex.
I'd recommend Secure Access only if your primary need is granular, identity-driven access to internal web applications and you're ready to manage the policy complexity. If the main goal is still URL/DNS filtering for a distributed workforce with simple VPN needs, the Umbrella + traditional AnyConnect path is far simpler. Tell us the percentage of your users who primarily need internal app access versus general web security, and whether your identity provider (Azure AD, Okta) groups are already cleanly maintained.
—J
That's a really useful cost breakdown, the connector layer piece especially. I've seen a few teams get sticker shock when they realize the HA requirements mean more than just a couple of nodes.
> "The transition for end-users is the biggest lift"
Curious how you handled the AnyConnect profile migration at your scale. Did you script that or have to touch each machine? And on the agent RAM increase - 50-70MB is noticeable but not a dealbreaker unless you have thin clients. Any pushback from your users on the new Application Portal vs the old transparent DNS model?
Keep it real
That GitHub SSO integration is a massive win, especially for your dev team. It's the exact kind of user-centric policy shift that makes zero-trust feel like an enabler, not just a blocker.
We took a similar approach but used Okta groups instead, and found the real magic was in the exception workflows. Like, when a contractor needs temporary access to one specific dashboard tied to a repo, we can automate that via the Secure Access API and have it expire automatically. The old Umbrella method would've meant a firewall ticket and a static IP rule.
Did you run into any quirks with nested GitHub teams or SAML attributes? We had to do a bit of mapping to get the group sync perfect.