The best cloud NAC for a large enterprise keeps working across hundreds of sites, several identity sources, and every type of device, without adding a team to run it.
Network access control (NAC) decides which users and devices can join the network, and what each of them can reach once connected. At enterprise scale, that decision is as much operational as technical. This guide sets out ten criteria for evaluating a cloud NAC, a proof of concept plan that tests them, and the points where a cloud NAC needs a companion tool.
Why large enterprises are moving NAC to the cloud
Market data shows the shift. Mordor Intelligence estimates the global NAC market at USD 5.19 billion in 2025, growing to USD 14.72 billion by 2030, a 23.2% compound annual growth rate. Large enterprises accounted for 70.3% of 2024 spending, and cloud-based deployment is forecast to grow fastest, at 25.2% a year through 2030.
On-premises systems still held 48.3% of 2024 NAC revenue, according to the same report. That shows how much of the installed base has yet to move, and how many large enterprises are about to face the choice this guide covers.
Three pressures drive the shift. Sites have multiplied, so a policy server per location no longer scales. Contractors, guests, and Internet of Things (IoT) devices now connect every day, and most of them sit outside the usual identity and endpoint tools. Security programs have also moved toward Zero Trust, which NIST SP 800-207 describes as replacing implicit trust based on network location with explicit, per-session decisions about users and devices.
The network port and the wireless network are where that decision first applies. NAC is the control that makes it.
What cloud NAC is, and what it is not
Cloud NAC is a network access control service where the Remote Authentication Dial-In User Service (RADIUS) policy engine runs in the cloud instead of on a local appliance. Switches, access points, and controllers stay in place as the enforcement points. They forward each 802.1X authentication request to the service, which checks the identity and returns the access policy to apply.
The protocols stay the same and the policy decision moves to the cloud. That distinction matters in evaluations, because the market uses the label for three different models.
- Cloud-native, vendor-neutral service. The policy engine runs as a service and enforces on equipment from several network vendors.
- Network-vendor cloud. Access control is built into one vendor's cloud-managed network, as with Cisco Meraki or Juniper Mist. It fits estates standardized on that vendor, and fits mixed estates less well.
- Appliance-based NAC. Physical or virtual servers, such as Cisco ISE or Aruba ClearPass, sometimes with cloud-based management. These offer deep policy control, with servers to size, patch, and replace at each site or region.
Large enterprises usually run a mix of network vendors after years of acquisitions and regional choices. That makes the first model the natural starting point for the shortlist, and the first criterion below.
Ten criteria for choosing the best cloud NAC
1. Vendor-neutral enforcement across the existing network
A cloud NAC built on standard RADIUS and 802.1X can enforce access on any compliant switch, controller, or access point. The network does not have to be replaced before access control improves. The evaluation should ask for the tested vendors and models, with a deployment guide for each.
2. Resilience and failure behavior
Moving the policy engine to the cloud removes local servers, and it also makes the path to the service part of the access path. Large enterprises should ask how the service is deployed across regions, what availability is committed in the contract, and what happens at a site when the link to the service is down. The answers should be specific and in writing.
3. Identity sources and directory consistency
The NAC should read from the directory where the business already defines people, such as Microsoft Entra ID, LDAP, or Active Directory. Group membership then drives network access, and a leaver loses access when the account is disabled. Post-merger estates add a harder test, which is whether the platform can work with two directories at once while the integration is finished.
4. Certificate-based authentication and PKI
Certificates remove shared passwords from network access. The Extensible Authentication Protocol-Transport Layer Security (EAP-TLS) method authenticates devices with a certificate that the mobile device management (MDM) platform distributes, for example Microsoft Intune. The question for large enterprises is who issues certificates, and who owns renewal and revocation.
A platform with built-in public key infrastructure (PKI) removes a set of systems that otherwise expire and drift apart. The trade-offs are covered in PKI built into Cloud NAC beats bolt-on services.
5. Coverage of unmanaged devices
Guests, contractors, personal devices, and IoT equipment make up a growing share of connections, and many of them cannot run an 802.1X supplicant. A cloud NAC should handle MAC authentication bypass for headless devices, place them in restricted segments, and use device profiling so that a MAC address is not the only proof of identity. Guest and contractor access through a captive portal should run from the same console. The model is explained in identity-driven access for BYOD, guests, and IoT.
6. One policy across wired, wireless, and every site
Policy drift is the quiet failure of multi-site NAC. When each deployment holds its own copy of the rules, buildings slowly diverge. The evaluation should confirm that dynamic VLAN assignment, role-based access, and access control lists come from one policy set, and that a change made once applies at every site and on both wired and wireless connections.
7. Data sovereignty and compliance
Authentication logs contain personal data. A global enterprise needs to know where those logs are stored, how long they are retained in each country, and whether the platform can produce evidence for frameworks such as NIS2, HIPAA, and PCI DSS. Data residency should be a contract term, not a slide.
8. Operations, visibility, and integration
Day-to-day use decides whether a platform stays in place. The evaluation should cover a single view of what is connected, log export to a security information and event management (SIEM) tool, application programming interfaces (APIs) for automation, and delegated administration so regional teams manage their own sites inside a global policy.
9. Total cost of ownership over three to five years
A license comparison understates the cost of appliance-based NAC. Hardware, high-availability pairs, power and cooling, refresh cycles, and the specialist labor to patch and operate the servers all belong in a three to five year model. For a cloud service, the equivalent check is how pricing behaves as sites, users, and devices grow.
The legacy NAC versus cloud-native NAC comparison lists the hidden costs of appliance-based deployments in more detail.
10. RADIUS transport security
RADIUS was designed for local networks. Its standard transport runs over UDP. Only the password field is hidden, using a shared secret and MD5, so usernames, device identifiers and the attributes that set access policy travel in clear text. In 2024 the Blast-RADIUS vulnerability (CVE-2024-3596) showed that an attacker on the path could also forge an Access-Accept. When the policy engine moves to the cloud, that traffic crosses the internet from every site.
A cloud NAC should carry RADIUS inside an encrypted channel. The standard option is RadSec, which is RADIUS over TLS (RFC 6614). The site and the service authenticate each other with certificates, and the whole exchange is encrypted. Where equipment does not support RadSec, an IPsec tunnel or a local proxy that converts RADIUS to RadSec are the usual alternatives. Buyers should ask which transport each tested model uses, who issues and renews the RadSec certificates, and how a site is protected when its equipment supports neither.
A scorecard for the shortlist
The table turns the ten criteria into questions a buying team can put to every vendor, and shows what a strong answer looks like.
How to run a proof of concept that reflects enterprise reality
A proof of concept on one lab switch proves very little. The seven tests below mirror the conditions that large enterprises actually face.
- Pilot one live site or one wireless network name (SSID), while every other site stays on the incumbent system.
- Add a new site by pointing its network equipment at the service, and record the time to full coverage.
- Remove access in two ways, by disabling a user in the directory and by revoking a certificate, and measure how quickly each takes effect across sites.
- Connect a printer and a camera, and confirm that each lands in a restricted segment.
- Cut the connection between one site and the service, and document what users and devices experience.
- Export logs to the SIEM and produce an audit report for one region.
- Capture traffic on a pilot site's uplink, and confirm that no RADIUS attribute can be read in transit.
Migrating from legacy NAC without a forklift upgrade
Each port, SSID or VLAN authenticates against one NAC at a time, so two systems cannot share an enforcement point. Migration is therefore phased, site by site, SSID by SSID, or VLAN by VLAN. A pilot site moves to the cloud service while the rest of the estate continues to authenticate against the incumbent.
The identity provider, the directory, the certificate authority, and the network hardware stay where they are. The incumbent is decommissioned after the last site has moved. Sites with appliances close to end of life, and small sites with no local IT staff, are usually the best first candidates. The wider case is made in how cloud NAC enhances Zero Trust for multi-site enterprises.
Where cloud NAC needs a companion tool
No NAC covers every requirement, and a requirements list should say so up front. Two areas deserve a close read. The first is continuous endpoint posture assessment, which depends on telemetry from endpoint detection and response (EDR) or MDM agents. The second is deep passive monitoring of industrial and operational technology networks.
Cloudi-Fi's Cloud NAC, for example, makes its decision from the certificate or credential presented and the directory attributes of the identity. Enterprises that need that signal should confirm how it will be supplied, whether by the NAC or by a companion tool.
Where Cloudi-Fi fits
Cloudi-Fi runs 802.1X authentication and policy enforcement from the cloud, through a Cloud NAC that keeps existing switches, access points, and controllers as the enforcement points. Cisco Meraki, Cisco Catalyst 9800, Aruba, and Fortinet equipment are supported, along with other 802.1X equipment. Identity comes from Microsoft Entra ID, LDAP, or Active Directory, and certificates can be distributed through Microsoft Intune.
Corporate access and guest access run on one platform, with one console and one set of logs. The platform is used by 100K+ sites, 500M+ users and devices in 90+ countries. Data privacy compliance is built in, with log storage and retention aligned to local regulation in over 70 countries.
Cloud NAC is worth evaluating when the operational burden of local infrastructure or fragmented access policies becomes difficult to justify. Five situations make that case particularly clear:
- Distributed branches: Assess whether each location’s size and support capacity justify deploying and maintaining a local NAC appliance.
- Growing IoT populations: Identify devices that bypass authentication today, then evaluate how to identify them and restrict their access.
- SASE and Zero Trust adoption: Check whether identity-based controls also govern admission to wired and wireless networks.
- Post-merger integration: Determine whether a common access policy can span existing directories and network equipment while integration proceeds.
- NAC hardware renewal: Use the refresh cycle to compare the cost and operational demands of another appliance generation with a cloud-delivered approach.
One customer, Baker & Baker, put the operational result this way at Zscaler Zenith Live Vienna.
"We are no longer using [our legacy NAC appliance] because Cloudi-Fi can do it, so we saved some licenses there, and some headache." Steffen Erler, Baker & Baker
Frequently asked questions
What is the best cloud NAC for large enterprises?
There is no single winner. The best cloud NAC is the one that enforces access across the enterprise's mix of network vendors, reads from its identity sources, covers unmanaged devices, and meets its data residency rules at an acceptable total cost. The ten criteria above turn that definition into a shortlist.
Is cloud NAC reliable enough for a large enterprise?
Reliability depends on the service architecture and on failure behavior at the site. Buyers should ask for regional deployment details, a contractual availability commitment, and documented behavior when a site loses its link to the service. A proof of concept should test that last point directly.
Can cloud NAC replace Cisco ISE or Aruba ClearPass?
In many estates, yes, in phases. Authentication and policy for 802.1X and MAC-based access usually map across. Posture checks and other functions that an incumbent system performs should be listed and checked one by one before a migration plan is agreed.
Conclusion
Choosing the best cloud NAC comes down to how well a platform holds up at scale. Vendor-neutral enforcement, resilient service design, encrypted RADIUS transport, identity-driven policy, coverage of unmanaged devices, regional data control, and a realistic cost model separate a strong platform from a good demo. Testing them in a proof of concept is the surest way to tell the difference.
Large enterprises evaluating a move away from appliance-based NAC can start with the Cloudi-Fi Cloud NAC and the questions in the scorecard above.
