Dev Blog
802.1X · MAB · Cisco · NAC · RADIUS · EAP-TLS · PKI · Monitor mode · Open mode · Guest WiFi · Wireless 802.1X · Policy Advisor · NIS2 · Cloud NAC

Keep it simple: enterprise-grade NAC without the enterprise project

23 September 2026 9 min read

NAC projects usually become difficult for two reasons: you do not know what is connected and you do not know what policy those devices need. The technology itself is not particularly complicated. The rollout is.

The safest approach is to separate discovery from enforcement. Enable 802.1X and MAB, but do not block anything. Let the network tell you what is connected, build the policy from that data, then enforce it.

This article shows the process using Cisco IOS-XE and Arbiter: open mode, monitor mode, MAB profiling, Policy Advisor, 802.1X, guest access and finally enforcement.

Why NAC deployments hurt

The pain is rarely the protocol. RADIUS is thirty years old and 802.1X is well understood. The pain comes from three places.

  • The platform. Policy nodes, databases, certificate infrastructure and high-availability pairs to build and maintain before a single device authenticates.
  • The unknown estate. Nobody has a complete list of what is plugged in, so nobody can predict what enforcement will break.
  • The policy set. Where do you start? What rules are required?

The first of those is a product decision and it is covered elsewhere: Arbiter runs the RADIUS, policy and PKI services as a managed platform with a small Edge appliance on site, so there is nothing to build. See why traditional NAC has to change. This post covers the other two.

Step one: enable authentication without enforcement

Start with authentication enabled but enforcement disabled. The estate then reports itself: every device authenticates, is profiled and appears in the inventory. The asset register gives you a live view of what is connected to your network.

Use both switch-level open mode and Arbiter monitor mode during discovery.

Open mode on the switch

On IBNS 2.0 a port is open until access-session closed is configured. It authenticates as normal, sends the result to RADIUS and logs everything, but forwards traffic regardless of the outcome. A reject cannot take a device off the network because the port was never gating traffic in the first place. On older IBNS 1.0 configurations the equivalent is authentication open.

Monitor mode in Arbiter

Monitor mode is the server-side equivalent, set as a flag on the authentication policy. Every condition is still evaluated and every policy hit is still counted, but any result that would have been a deny is coerced into a permit and VLAN and captive-portal attributes are suppressed so nothing gets moved. The authentication log still shows the denial that would have happened, marked with an eye badge.

After a week in monitor mode the log holds every device that would have been denied, with its vendor, device class and switchport. That is the list you work through before enforcing.

The wired configuration: Cisco 802.1X and MAB

The configuration below is taken from a Catalyst 9200 running IOS-XE 17.6 in our lab, with the secrets removed. It uses IBNS 2.0 (access-session and control policies) rather than the older authentication commands, which are deprecated on current IOS-XE. The only Arbiter-specific values are the addresses of the two Edge appliances.

AAA, RADIUS and CoA

! ---- AAA and the Arbiter Edge pair as RADIUS servers ----
aaa new-model

radius server ARBITER
 address ipv4 10.0.20.10 auth-port 1812 acct-port 1813
 key <shared-secret>

radius server ARBITER2
 address ipv4 10.0.20.11 auth-port 1812 acct-port 1813
 key <shared-secret>

aaa group server radius ARBITER
 server name ARBITER
 server name ARBITER2
 ip radius source-interface Vlan11

aaa authentication dot1x     default group ARBITER
aaa authorization network    default group ARBITER
aaa accounting identity      default start-stop group ARBITER
aaa accounting network       default start-stop group ARBITER
aaa accounting system        default start-stop group ARBITER

! Attributes the policy engine uses to identify the switch and the port
radius-server attribute 6  on-for-login-auth
radius-server attribute 8  include-in-access-req
radius-server attribute 25 access-request include
radius-server attribute 32 include-in-access-req format %h
radius-server dead-criteria time 10 tries 3
radius-server deadtime 1

! Change of Authorization, so a policy change lands without bouncing the port
aaa server radius dynamic-author
 client 10.0.20.10 server-key <shared-secret>
 client 10.0.20.11 server-key <shared-secret>
 auth-type any

dot1x system-auth-control
access-session mac-move deny

The dynamic-author block enables CoA, which moves a device onto its real policy as soon as it is classified rather than at the next reauthentication. Attribute 32 sends the hostname as NAS-Identifier so the switch is named rather than numbered in the logs. Arbiter normalises MAC address formats on ingest, so there is no need to pin Calling-Station-Id to a particular format on the switch.

The access port, in discovery mode

! ---- the control policy: try 802.1X, fall back to MAB ----
class-map type control subscriber match-all DOT1X_NO_RESP
 match method dot1x
 match result-type method dot1x agent-not-found
class-map type control subscriber match-all DOT1X_FAILED
 match method dot1x
 match result-type method dot1x authoritative
class-map type control subscriber match-all MAB_FAILED
 match method mab
 match result-type method mab authoritative
class-map type control subscriber match-all AAA_SVR_DOWN
 match result-type aaa-timeout
class-map type control subscriber match-any IN_CRITICAL_AUTH
 match activated-service-template CRITICAL_AUTH_ACCESS

service-template CRITICAL_AUTH_ACCESS
 description Critical Auth fallback
 vlan 21

policy-map type control subscriber INT-AUTH-POLICY
 event session-started match-all
  10 class always do-until-failure
   10 authenticate using dot1x priority 10
 event authentication-failure match-first
  5  class DOT1X_FAILED do-until-failure
   10 terminate dot1x
   20 authenticate using mab priority 20
  10 class AAA_SVR_DOWN do-until-failure
   10 authorize
   20 pause reauthentication
   30 activate service-template CRITICAL_AUTH_ACCESS
  20 class DOT1X_NO_RESP do-until-failure
   10 terminate dot1x
   20 authenticate using mab priority 20
  30 class MAB_FAILED do-until-failure
   10 terminate mab
   20 authentication-restart 60
 event agent-found match-all
  10 class always do-until-failure
   10 terminate mab
   20 authenticate using dot1x priority 10
 event aaa-available match-all
  10 class IN_CRITICAL_AUTH do-until-failure
   10 clear-session
 event authentication-success match-all
  10 class always do-until-failure
   10 authorize
 event violation match-all
  10 class always do-until-failure
   10 restrict

! ---- the port template. Note what is NOT here yet: access-session closed ----
template PORT-AUTH-TEMPLATE
 dot1x pae authenticator
 dot1x timeout tx-period 3
 dot1x max-reauth-req 3
 mab
 access-session port-control auto
 authentication periodic
 authentication timer reauthenticate server

! ---- the access ports ----
interface range GigabitEthernet1/0/2-10
 switchport mode access
 switchport access vlan 10
 switchport voice vlan 11
 source template PORT-AUTH-TEMPLATE
 service-policy type control subscriber INT-AUTH-POLICY
 spanning-tree portfast
 spanning-tree bpduguard enable

The significant lines:

  • The absence of access-session closed. In IBNS 2.0 a port is open unless you close it, so discovery is the default state and enforcement is the line you add later.
  • event session-started / authenticate using dot1x, then DOT1X_NO_RESP / authenticate using mab: this is the order. 802.1X is tried first and a device that never answers EAP falls through to MAB. In IBNS 1.0 this was the single line authentication order dot1x mab; in 2.0 it is explicit, which is more verbose but far easier to debug.
  • dot1x timeout tx-period 3 with dot1x max-reauth-req 3: how long a silent device waits before MAB takes over. Three seconds, three attempts, so a printer reaches DHCP in about nine seconds rather than the 90 the defaults give you.
  • AAA_SVR_DOWN / activate service-template CRITICAL_AUTH_ACCESS: if both Edge appliances are unreachable, ports fall into a known VLAN instead of failing shut. Authentication is in the path of everything, so decide now what happens when it is unavailable.
  • authentication timer reauthenticate server: take the reauthentication interval from the RADIUS reply rather than hardcoding it, so the policy decides.
  • source template PORT-AUTH-TEMPLATE: every access port inherits one template. That is what makes enforcement a single line in a single place instead of a change on every port.

Leave that running for a week. Every device on the estate will authenticate, be profiled and appear in the inventory and nothing will be denied.

Step two: let the Policy Advisor write the rules

At this point the inventory holds several hundred endpoints, all of them landing on Default Deny in the logs. That has to become a policy set.

Rather than starting from an empty rule engine, Arbiter reads the endpoints that are failing and proposes rules that would match them.

The nightly pass

A nightly job examines endpoints hitting Default Deny, groups them by vendor and Fingerbank attributes and writes a candidate rule whenever at least three endpoints share a pattern. It skips anything already covered by an active policy and anything you have dismissed, so the list stays short and does not nag.

The nightly generator currently covers Wired MAB only. This is deliberate: MAB is where the unknown devices are and where a wrong rule is most expensive. Classifying those devices in the first place is its own problem, covered in the MAB profiling chicken and egg.

Send to Advisor

The other direction is manual and immediate. Filter the inventory to the devices you care about, tick them and use Send to Advisor.

The advisor reads the selection and builds the match for you. If everything you ticked shares a device class it matches on that class. If you have selected a mix, it builds an OR across the classes. If the devices are not classified yet, it falls back to the OUI, which is the case below: three Cisco endpoints with no class, so the proposed condition is an OUI match.

The advisor picks the match and proposes a name. You choose the access profile, which determines what the device actually receives and nothing is written until you press Create Rule.

Worked through this way, a few hundred unknown endpoints usually reduce to a dozen or so rules: printers, cameras, phones, access points and building management.

Wireless: the same policy set on WPA2-Enterprise

On wireless the alternative to 802.1X is a shared passphrase, which identifies nobody and is rarely rotated. On a Catalyst 9800 the configuration is short.

! ---- method lists ----
aaa authentication dot1x ARBITER-DOT1X group ARBITER
aaa authorization network ARBITER-NET  group ARBITER
aaa accounting  identity ARBITER-ACCT  start-stop group ARBITER

! ---- corporate SSID, WPA2-Enterprise ----
wlan CORP 1 Corp
 security wpa wpa2
 security wpa wpa2 ciphers aes
 security dot1x authentication-list ARBITER-DOT1X
 no shutdown

! ---- policy profile: let RADIUS drive VLAN and ACL and accept CoA ----
wireless profile policy CORP-POLICY
 aaa-override
 nac
 accounting-list ARBITER-ACCT
 vlan 10
 no shutdown

aaa-override lets the RADIUS reply set the VLAN and any filter, so one SSID can place different users on different VLANs. nac enables CoA handling, so the controller acts on a change of authorization instead of discarding it.

The policy set you built for wired does not need rewriting. The same identity and the same device classes apply and the access profile decides what a device gets on each medium.

Guest access: isolated and logged

Guest access has three requirements: give visitors internet, keep them off everything else and record who connected and when.

! ---- redirect ACL: permit means REDIRECT, deny means leave alone ----
ip access-list extended REDIRECT-TO-PORTAL
 deny   udp any any eq domain
 deny   ip  any host 10.0.20.10
 deny   ip  any host 10.0.20.11
 permit tcp any any eq www
 permit tcp any any eq 443

! ---- open guest SSID, MAC filtering hands the client to RADIUS ----
wlan GUEST 2 Guest
 no security wpa
 mac-filtering ARBITER-NET
 no shutdown

wireless profile policy GUEST-POLICY
 aaa-override
 nac
 vlan 90
 no shutdown

In a redirect ACL, permit means redirect this traffic to the portal and deny means pass it through untouched. Exempt DNS and the portal addresses, then redirect web traffic. Inverting the two is the common failure: guests either never see the portal or cannot reach it.

Arbiter returns the redirect URL and ACL name in the Access-Accept, the guest signs in and a CoA reauthorises the session onto its real profile.

Certificates without a certificate authority

Everything above works with MAB and with credential-based 802.1X, but the strongest wired and wireless authentication is certificate-based EAP-TLS. It is phishing-resistant and does not depend on the user's password.

EAP-TLS normally means running a certificate authority, which is a project in itself. Arbiter gives each tenant its own PKI at tenant creation: it signs the RADIUS server certificate, it can issue endpoint certificates and renewal is automatic. If you already run a CA you can bring it instead.

For Intune-managed Windows devices, enrolment is over SCEP, so there is no NDES server to stand up and no on-premises certificate infrastructure to maintain. That path is written up separately in 802.1X certificates from Intune without NDES.

Step three: enforce

By now the inventory is populated, the policy set matches the estate and the logs have been quiet for days. Going live is one line, in one place.

template PORT-AUTH-TEMPLATE
 access-session closed

Every port sourcing the template closes at once. Turn monitor mode off on the authentication policy at the same time and the coerced permits become real verdicts. Nothing else changes: the discovery configuration and the enforcement configuration differ by that one line.

Do it on one switch or one floor before you do it everywhere. The rollback is no access-session closed.

Keep it simple

Discovery first, enforcement last, with one line changed between them.

The enforcement phase is still standard 802.1X, EAP-TLS and RADIUS on the switches you already own. The difference is how you get there: no stage of the rollout puts the network at risk and the rule set is built from observed traffic rather than by hand.

NAC gets deployed because someone asked a question you could not answer, usually in a NIS2 gap assessment, a cyber-insurance renewal or a customer audit. The rollout should not require a six-month infrastructure project.