Most network access control projects fail on the devices nobody planned for, not on the laptops in the demo. A NAC platform has to admit managed endpoints with strong certificate-based authentication, recognise printers, cameras, medical and OT devices that cannot run a supplicant, check posture with your MDM and EDR tools, and keep working when the RADIUS service is under load. This vendor-neutral buyer's guide helps network, security and identity teams set requirements, weigh capabilities and run a proof of concept for NAC platforms, whether on-premises or cloud-delivered. How 802.1X, EAP methods, MAB and RADIUS work is covered in the Network Access Control (NAC) Guide and is not repeated here.
Key takeaways
- Buy for EAP-TLS first. Certificate-based 802.1X for managed devices is the baseline; check support for EAP-TLS 1.3 (RFC 9190), server certificate validation and revocation checking.
- Profiling decides the outcome for IoT and OT. Most devices that cannot authenticate will be admitted on a MAC address plus a profile, so test profiling accuracy on your own devices.
- Posture should come from the tools you already trust. Integration with MDM and EDR is usually more reliable than a separate NAC agent's checks.
- Certificate lifecycle is part of the purchase. Device certificates must be issued, renewed and revoked automatically, or NAC becomes the source of outages.
- Weight enforcement and operations, not feature count. Change of Authorization, monitor mode, scale and RADIUS resilience matter more in production than a long integration list.
Define requirements
- Device population: how many corporate laptops, mobiles, BYOD, guest, IoT, OT and medical devices connect, on which sites, and over wired, wireless or VPN? Which of them can run an 802.1X supplicant?
- Network estate: switch and wireless vendors and software versions, support for RADIUS CoA, multi-auth host modes and downloadable ACLs, and whether SD-WAN branches or remote sites need local survivability.
- Identity sources: directory and identity provider (on-premises Active Directory, Entra ID or another cloud directory), and whether machine and user authentication are both required.
- PKI: do you have a private CA that can issue device certificates through SCEP, PKCS or ACME from your MDM, and who owns renewal? See the Machine Identity, PKI and Certificate Lifecycle Guide.
- Posture sources: MDM and EDR platforms in use, and which signals (encryption, OS version, EDR health) should change access.
- Outcomes: admission only, or also segmentation (VLANs, ACLs, security group tags) and automated quarantine from SIEM or EDR alerts. See the Network Segmentation Guide.
- Deployment and compliance constraints: on-premises, cloud-delivered or hybrid RADIUS; data residency; sector rules for OT or clinical networks.
Capability areas
| Area | What to look for |
|---|---|
| Authentication | 802.1X (IEEE 802.1X-2020) with EAP-TLS including TLS 1.3, TEAP for machine plus user chaining, server name matching, OCSP or CRL revocation checks, anonymous outer identity; MAB only as a controlled fallback |
| Device profiling | Passive (DHCP, LLDP, HTTP user agent, traffic) and active (SNMP, port scans where safe) profiling, confidence scores, a maintained device library, and support for MUD URLs (RFC 8520) where devices emit them |
| Posture: agent | Persistent or dissolvable agent, supported operating systems, checks for disk encryption, patch level, firewall and EDR status, remediation guidance for the user |
| Posture: agentless | Compliance state pulled from MDM and EDR by API, plus network-based checks; clear statement of what cannot be verified without an agent |
| Certificate lifecycle | Built-in or integrated CA, SCEP or ACME issuance through MDM, renewal before expiry, revocation on device retirement, support for hardware-bound device identities (IEEE 802.1AR IDevID and LDevID) |
| Integrations | MDM compliance (for example the Microsoft Intune compliance retrieval API), EDR, SIEM, ITSM, firewalls and SASE for identity-aware policy, threat-triggered quarantine |
| Enforcement | Dynamic VLAN, downloadable ACLs, group tags, RADIUS CoA and disconnect, guest and onboarding portals, multi-vendor switch and wireless support |
| Operations | Monitor and low-impact modes, policy simulation, per-site rollout, RADIUS high availability, scale per node, upgrade without outage, readable authentication failure logs |
| Platform security | RADIUS over TLS or protection against Blast-RADIUS style attacks, per-device shared secrets, admin MFA and roles, API token management, audit logging |
For the identity side of IoT and OT admission, see the Device and IoT Identity Guide and the OT Security Platform Buyer's Guide.
Evaluation criteria
The weights below are illustrative for a mixed corporate and IoT estate. Adjust them to your requirements before scoring, and score each criterion 1 to 5 on evidence from the proof of concept, not from datasheets.
| Criterion | Illustrative weight | Evidence that earns a high score |
|---|---|---|
| Certificate-based authentication and PKI integration | 20% | EAP-TLS with your MDM-issued certificates works on all managed platforms, revocation is enforced, renewal is automatic |
| Profiling accuracy for headless, IoT and OT devices | 20% | High correct-classification rate on your device sample; unknown devices land in a restricted policy, not open access |
| Posture and MDM/EDR integration | 15% | Compliance changes access within minutes; EDR alerts can trigger quarantine through CoA |
| Enforcement across your network vendors | 15% | CoA, ACLs and VLAN assignment work on your switch and wireless models and versions |
| Operations, rollout tooling and resilience | 15% | Monitor mode reports, policy simulation, HA failover without re-authentication storms, clear troubleshooting logs |
| Platform security | 10% | RADIUS over TLS or equivalent, admin MFA, scoped API tokens, audit trail |
| Total cost and licensing model | 5% | Predictable licensing for IoT device counts and guest volumes; no paid add-on for core posture |
Smaller organisations with mostly wireless, cloud-managed devices often weight cloud-delivered RADIUS and MDM integration higher. Hospitals, factories and campuses usually weight profiling and enforcement higher.
Questions to ask vendors
- Which EAP methods do you support as server, including EAP-TLS over TLS 1.3 and TEAP, and how do you check certificate revocation?
- Show how you identify a device that presents only a MAC address, and what happens when the profile confidence is low or the MAC is randomised.
- How large is your device profile library, how often is it updated, and can we add our own profiles for OT and medical equipment?
- Which MDM and EDR integrations are API-based, how often is compliance polled, and how fast does a change in compliance reach the switch port? For Intune, do you use the compliance retrieval service with the Intune device ID in the certificate SAN?
- Can you issue, renew and revoke device certificates yourselves, or do you rely on our CA, and what happens to admission when a certificate expires?
- Which switch and wireless models and versions have you tested for CoA and downloadable ACLs?
- How do you protect RADIUS traffic between network devices and your servers, and how are shared secrets managed?
- What is the failure behaviour if your cloud service or a RADIUS node is unreachable from a site?
- How are your admin accounts and API tokens protected, and is every policy change logged with the actor?
Red flags
- Demonstrations that use only PEAP with passwords or only MAB, with EAP-TLS presented as a later phase.
- Posture that is reported but not enforced, or enforced only at connection time with no CoA when a device falls out of compliance.
- Profiling accuracy claims that cannot be tested on your own devices during the proof of concept.
- No answer on certificate renewal and revocation, leaving device lifecycle to manual processes.
- Unknown devices defaulting to the corporate network when profiling fails.
- One shared RADIUS secret for every network device, or no plan for RADIUS over TLS.
- Licensing that charges per posture check or makes IoT device counts unpredictable.
Proof of concept
- Pick two or three representative sites (one wired campus, one wireless office, one site with IoT or OT) and your actual switch and wireless models.
- Run the platform in monitor mode for two weeks and compare its inventory and profiles against your asset inventory and CMDB.
- Enrol managed Windows, macOS, iOS and Android devices with MDM-issued certificates and authenticate with EAP-TLS; revoke one certificate and confirm access is removed.
- Admit a sample of at least 20 headless device types and record the classification rate, false positives and time to profile.
- Make a test device non-compliant in MDM and raise a test alert in EDR; measure the time until the port or SSID moves the device to quarantine.
- Fail a RADIUS node or cut a site's link to the cloud service during working hours on a pilot segment and observe re-authentication behaviour.
- Move the pilot to low-impact then closed mode for one ring, confirm the rollback switch returns ports to open authentication, and review the help desk tickets raised.
- Score each vendor against the evaluation table and record the evidence behind every score.
How NHI Mgmt Group can help
We provide independent requirements and evaluation support for device identity, network access and NHI programmes. Browse vendors in our products directory or contact us.
Related NHI Mgmt Group resources: Network Access Control (NAC) Guide · Device and IoT Identity Guide · Device Trust and Posture Guide · IoT Security Buyer's Guide · SASE and SSE Guide