NAC (Network Access Control) is expensive, complex and usually softened in dozens of places. For us at Rheintec, NAC is outdated technology that most companies no longer need, especially in the context of Zero Trust with SSE.
History of NAC
In - let's call them - "classic" network architectures, NAC is often used to enable authentication at layer 2 level within a "trusted zone", i.e. the internal network. The approach is based on limiting access to the trusted zone as much as possible so that attackers cannot access internal resources in the network.
In the best case scenario, NAC uses device certificates and the 802.1X protocol for WiFi and LAN. The clients then authenticate themselves transparently in the local network and thus gain access to the trusted zone and therefore to internal applications. Following this concept, the attacker is locked out of this zone in the perfect world and cannot attack it.
Reality check
NAC only works effectively for managed devices, i.e. for user laptops and workstations - in other words, everything on which certificates can be rolled out in a controlled manner. This means that IoT and OT are usually out of the picture, which is why companies either fall back on MAC-based authentication (easy to spoof, not cryptographically secure!) or disable NAC for these systems/ports. Effectively, this leads to the sacred internal zone being filled with holes. An attacker therefore looks for precisely these systems in order to quickly and easily overcome the internal NAC.
NAC cannot be used for servers or cloud environments anyway because they are located in closed rooms or cannot be physically "connected".
Furthermore, NAC is extremely time-consuming to operate because new devices - especially IoT devices - are constantly being added, which then have to be laboriously authorized and maintained with their MACs in "whitelists".
Why NAC with SSE components no longer provides any added value
We need to reflect on the historical network concept from the beginning: defining "trust" as the ability to access the layer 2 network and thus gain access to internal systems makes no sense. Instead, we are rethinking: We ALWAYS verify and segment every request from every user on every device to every application using a broker - i.e. the Secure Service Edge (SSE). Every single request, its authenticity, authorization and extended context is evaluated and then approved or blocked. Just because someone comes from the "trusted zone", the internal network, does not mean that they have access to anything.
The only requirement we place on a network: It must enable the connection to the broker - i.e. the SSE component. The local network therefore degenerates into a "dumb" Internet access/hotspot. WiFi and LAN for the user networks are simply considered completely isolated - from all IoT, OT and application segments - and are no longer given any access to them because they are no longer needed.
And what does this mean? If access to the network no longer helps an attacker, then I no longer need to limit access to the network! The cost, complexity and operation of NAC can be completely eliminated and the same budget can be used to finance a SASE transformation that creates 100 times more added value for a company in terms of security, simplicity, user experience and cost-effectiveness.
How can I save even more costs?
Good question, simple answer: If a network does not have to do more than (micro-) segment individual networks, provide WiFi and LAN and enable east-west traffic between locations for IoT, OT and servers - and this should be as simple as possible - then we now throw out local firewalls, license-based switches and access points. In this case, we use Ubiquiti. Ubiquiti offers all this at absolutely unbeatable prices: CAPEX compared to Palo, Aruba, Fortinet and Cisco divided by three. We reduce OPEX completely due to the non-existent license costs!
So we build a simple, resilient network that primarily serves as Internet access and combine it with a security-strong SSE solution such as Zscaler or Cloudflare.
