ENTERPRISE NETWORK SECURITY · 25 OCTOBER 2026

Wired 802.1X and NAC: a commissioning worksheet

A switch port can be physically live while still enforcing the wrong access decision. Wired 802.1X commissioning must prove the identity path, authorization result, fallback behavior and recovery process for every endpoint class. This worksheet helps facilities teams and network owners test those controls without treating a successful login as complete acceptance.

Illustrative visual reference photographs, not completed Cyber FTTH Mart project evidence

What 802.1X controls

The IEEE 802.1X overview describes port-based network access control as a way to regulate network access and guard against unidentified or unauthorized parties. At a wired edge, three roles matter: the endpoint or supplicant, the access switch or authenticator, and the authentication server, commonly reached through RADIUS.

Authentication answers who or what is connecting. Authorization decides what that identity may reach. Accounting and logs record what happened. Commissioning must verify all three. A valid certificate with the wrong VLAN, downloadable ACL, security group or session timeout is still a failed deployment.

Build the endpoint matrix before enforcement

List managed computers, employee devices, IP phones, printers, cameras, access controllers, building automation gateways, servers and temporary contractor devices. For each class, record whether it supports an 802.1X supplicant, whether a device certificate can be issued, whether it appears behind another device, and whether uninterrupted operation is safety or business critical.

This prevents a common rollout failure: designing only for managed laptops, then discovering that cameras, printers, intercoms or phones cannot follow the same flow. Use MAC Authentication Bypass only as a controlled exception for devices that cannot perform stronger authentication. A MAC address is easy to observe and reproduce, so MAB should lead to minimum required access and active monitoring.

Prefer certificate-based identity where practical

EAP-TLS can provide strong machine or user authentication when certificate issuance, trust, renewal and revocation are operated correctly. Microsoft's current EAP-TLS certificate requirements explain server-purpose, trust-chain and name checks. Its NPS certificate template guidance covers server certificate requirements for supported Windows Server versions.

Record the issuing CA, naming rule, required extended key usages, trust anchors, validity period, renewal mechanism, revocation reachability and time source. Test a valid certificate, an expired certificate, an untrusted issuer, a revoked certificate where supported, and a server-name mismatch. Do not disable server validation merely to make onboarding easier.

Separate rejection from infrastructure failure

The policy must distinguish a rejected credential, no 802.1X response, an unavailable RADIUS server and a broken path between the switch and server. These conditions should not automatically receive the same access. Cisco's current 802.1X configuration guide documents critical-port behavior and reinitialization when the authentication server returns. Exact features and syntax vary by platform and release.

Choose fail-open, fail-restricted or fail-closed behavior per endpoint class and operational risk. A lift controller, emergency voice endpoint and office laptop may need different outage policies. If a critical VLAN is used during RADIUS failure, define its permitted services and test that endpoints leave it after recovery.

Design MAB as an exception path

For every MAB device, keep an inventory owner, switch port, expected MAC address, equipment type, approved network role and retirement date. Place cameras, printers, readers and automation devices into dedicated least-privilege segments. Verify that a copied MAC on a different port does not receive more access than intended and generates an actionable alert where supported.

HPE Aruba Networking's wired policy enforcement guide frames secure wired access around profiling, authentication, authorization and posture. Profiling adds context, but it is not proof of identity. Treat vendor or device fingerprints as supporting signals, not replacements for strong credentials.

Calculate the authentication load

A rollout can work in a pilot and fail when an entire building reconnects after a power interruption. Estimate the peak transaction rate before acceptance:

Example: 1,200 wired endpoints expected to recover within five minutes require an average of 4 authentications per second before retry overhead and other services. Test a controlled burst, inspect switch queues and RADIUS latency, and confirm that logging, directory lookups, certificate validation and policy evaluation keep pace.

Commission one policy state at a time

1. Verify NTP, DNS, certificates and management reachability before testing users.
2. Confirm each switch is registered with the correct RADIUS source address and secure secret handling.
3. Test a valid managed endpoint and record the assigned VLAN, ACL or role.
4. Test an invalid identity and confirm that unauthorized production access is blocked.
5. Test an approved non-supplicant endpoint and one unknown MAC.
6. Test a phone with a downstream computer in the configured host mode.
7. Reconnect the cable, move the endpoint to another port and trigger reauthentication.
8. Stop one RADIUS node, then all nodes in an approved window, and observe behavior.
9. Restore the server and verify automatic session recovery from the critical state.
10. Confirm every event is time-aligned across switch, RADIUS, identity store and monitoring.

Use an acceptance matrix

Build rows for each endpoint class and columns for valid authentication, invalid credential, no response, unknown MAC, RADIUS unavailable, authorization result, DHCP and DNS access, application reachability, log evidence and recovery. Record the exact observed state. Avoid a generic pass mark that hides whether a device reached the correct segment.

Test representative access switches and software versions. A result on one model does not prove identical timer, host-mode or failure behavior elsewhere. In a multi-vendor campus, verify RADIUS attributes and dynamic policy interpretation on each platform.

Handover checklist

1. Endpoint classes and approved authentication methods are documented.
2. RADIUS nodes, switch clients, source addresses and redundancy paths are recorded.
3. Certificate trust, naming, renewal and revocation dependencies are validated.
4. Every policy returns the intended VLAN, ACL or role.
5. MAB devices have named owners and least-privilege access.
6. Unknown and rejected endpoints cannot reach protected services.
7. Voice and downstream-device host modes are tested.
8. Server-unavailable behavior is approved by endpoint class.
9. Recovery after RADIUS restoration is automatic or safely documented.
10. Peak reconnect load and authentication latency are measured.
11. Switch, RADIUS and identity logs use synchronized time.
12. Break-glass administration is controlled and tested.
13. Exceptions have an owner, expiry date and corrective action.
14. Configuration backups and policy exports match the commissioned state.

Commissioning worksheet structure

Use separate sheets for infrastructure dependencies, endpoint inventory, authentication policy, certificate lifecycle, MAB exceptions, RADIUS failure behavior, scale testing and final exceptions. Link each test row to switch output, RADIUS event, authorization attributes, packet capture when required, timestamp and approver.

Related reading: use the VLAN and switch handover worksheet to document segments returned by NAC, the IP addressing, DHCP and DNS worksheet for post-authentication services, and the switch resilience worksheet for failure paths.