Today, most enterprises use different products to secure user access in campus networks compared with remote workers. In campus environments, we see enterprises invest in NAC products, and/or deploy enhanced security capabilities. Specific examples include things like FortiNAC, Cisco SDA / ISE, Aruba ClearPass, ExtremeControl, etc…. We also see see configuration of technologies including DHCP snooping, IP Source Guard, MACsec, 802.1X, private VLANs, dynamic ARP inspection, etc.
However, for remote workers, enterprises primarily invest primarily in VPN or (more recently) ZTNA technologies. But, as employees shift to hybrid work (whereby they work regularly both remotely and in the office), this use of multiple products is inefficient, as it leads to
- Remote workers having different experiences for connecting (such loading VPN clients or authenticating differently).
- Separate policy engines, that requires enterprises set and manage policy in multiple places, increasing likelihood of inconsistency
- Swivel chair troubleshooting across multiple consoles
- Paying for for two separate products and the associated management infrastructure
Given this inefficiency, we think this area is primed for disruption. We believe that applying ZTNA products to campus networks is feasible and valuable. This isn’t just Gartner analysts being academic, because our end-user clients are asking about this too… Conversations go like this…
I use cloud-based ZTNA service to support remote workers, and I like the security, visibility, and flexibility of the “as-a-service” model. Why can’t I use the same solution in on-prem campus and branch environments? Why do I have to deal with complex, tedious vlan, ACL, port, 802.1x and NAC configurations?
In other words, why can’t the network (hardware) be dumb and instead apply security in a simple software stack. In some cases, we’re hearing that users have gone back to the office and things are worse than at home…they’re complaining to IT that “nothing works anymore…i can’t login and my apps are slow and/or not working”.
While some ZTNA vendors do technically support on-premises workers, few ZTNA offerings are targeted, focused and/or specifically optimized for campus/branch environments. But what if they were? What if we could use ZTNA on campus the way we do at home? A single software solution (versus separate disparate solutions) enables
- Single security policy that spans remote workers and campus workers
- Common experience for end-users whether working remotely or on-prem
- Simpler troubleshooting (i.e., one solution versus multiple)
- Better economics and efficiency (using one solution for 2 use cases)
But why aren’t more vendors doing this already? The primary reason vendors haven’t invested in ZTNA to support on-campus workers is because of commercial reasons. Don’t get me wrong, there are technical challenges, too (but they can be overcome). It is disruptive to the status quo for existing establised NAC/switching vendors and likely cannibalistic to existing revenue. The lack of investment is NOT because it isn’t the right approach. However, inefficiencies like this only last so long in markets before vendors step in and disrupt (See SDWAN).
ZTNA Anywhere: So as we shift to hybrid work, we are hoping that vendors get out in front of this problem with expanded/new offerings. Think of it as ZTNA Anywhere or Universal ZTNA.
Along these lines, we just published research (aimed at the vendor community) to address this issue.
Campus Network Security and NAC Are Ripe for Market Disruption
Summary: Enterprises spend billions to secure campus networks via a combination of switching features and NAC — an approach ripe for disruption with the shift to hybrid work. Product leaders should extend ZTNA products to campus environments to drive revenue and enterprise value, but they need to act fast.
Regards, Andrew
The Gartner Blog Network provides an opportunity for Gartner analysts to test ideas and move research forward. Because the content posted by Gartner analysts on this site does not undergo our standard editorial review, all comments or opinions expressed hereunder are those of the individual contributors and do not represent the views of Gartner, Inc. or its management.
2 Comments
Andrew,
you are right, there is no reason why it cant be one unified model built under the assumption that the network should be just a transport, and all the other connectivity/security stuff can be achieved by the same unified architecture everywhere – whether its remote user at home/in-transit/branch/campus – whether it is ztna or something else.
A slight amount of irony is that all “ztna” solutions are in-fact just transplanting a lot of stuff that used to be done by the transport (as you identified in your blog about the campus) into a different “module” so to say, that is one massive over kill and if we look closely, is one area prime for disruption too
Gopa.
I just came across your post and did a mental fist-pump like I’d just dropped a birdie on 18 to close a round of 68.
From October to December, 2020, as a Principal Consultant for a large carrier’s professional services division, I was working on SOW to a large and very well-known Eastern university for a kind of ‘segmentation architecture’.
I first worked in concert with our business architecture team – crafting questions and lines of analysis to understand the huge array of the client’s applications and use cases.
I analyzed industry technology trends (doing a lot of ramping up on ZTA, ZTN, and ZTNA, and the then-barely 2-months old NIST 800-207 architecture), reached out to internal teams about our internal capabilities and offers, and then developed and delivered an architecture document deliverable outlining my findings and suggesting… basically exactly what you just wrote in your blog.
I still believe it was the right plan, since they already used so many cloud-based products, had most of their staff remote, and were at a point where an overlay solution could handle 80+ % of their use cases and user base. In summary – ‘ZTNA Everywhere’ could address their requirements, be implemented gradually, and set them up with a 5-year plan that was adaptable and would grow with them, while introducing a practical, but modernized, implementation of ‘Intent-Based Networking’ (the relevant term at the time) especially for the centralized policy management aspect (what today we would likely call SASE).
So thanks for the blog post, and – yeah… all of that… what you just said.