Network access control: plan the rollout around certificates and exceptions

The managed laptops connect successfully, but a label printer stops working when the next switch is moved into enforcement. The device was absent from the pilot inventory. An emergency bypass restores the warehouse, and nobody is quite sure when that exception can be removed.

Network access control should reduce uncertainty about which devices can connect and what they can reach. A rollout that discovers essential equipment only after denying it creates a growing set of emergency permissions. The better starting point is a device and dependency inventory, followed by a deliberately varied pilot.

Distinguish authentication from the access decision

Network admission is only one boundary. Use the segmentation flow record to decide which services an admitted device can reach.

In an 802.1X deployment, the endpoint’s supplicant participates in authentication through the network device to an authentication service. A successful authentication establishes a basis for the access decision. The resulting network permissions still need to match the device’s role.

Do not treat “authenticated” as a reason to allow unrestricted access. A meeting-room unit, a managed workstation and a production controller have different communication requirements. Connect the access policy to the segmentation rules and tested dependencies for each group.

Also distinguish proof of identity from device health. If the proposal includes posture checks, ask exactly what they measure, how recent the evidence is and what happens when the checking service is unavailable. Record those as separate policy decisions.

Make certificate operations part of the project

Certificate-based EAP-TLS can support strong device or user authentication, but it brings an operational dependency on issuing and maintaining suitable certificates. Microsoft’s NPS certificate requirements cover trust, intended certificate purpose and server identity checks. Apply the requirements for the actual platform and authentication method rather than copying a generic profile.

Test enrolment before first network access, renewal before expiry, revocation behaviour, device replacement and recovery after a management failure. A machine that needs the protected network to obtain its first credential has an onboarding dependency to solve.

Configure clients to validate the intended authentication server. Do not train users to accept an unexpected certificate prompt as the way to get online. Plan certificate changes so the trusted identity and client configuration remain aligned.

Assign ownership across network operations, endpoint management and the certificate service. An alert about approaching expiry is useful only if someone can renew the credential and distribute the required configuration before users lose access.

Handle equipment that cannot use 802.1X

Some printers, sensors and specialist devices will need an alternative approach. Cisco’s MAC Authentication Bypass guide describes a mechanism for devices without an 802.1X supplicant. A MAC address does not provide the same proof as possession of a protected credential and can be imitated. Treat such access as an explicit exception.

For each exception, record the physical or operational context, device owner, permitted destinations and review date. Restrict the access to the work the device needs. A printer’s inability to authenticate should not automatically grant it the same reach as a managed employee laptop.

Set a review event that can actually change the decision: replacing the device, upgrading its supported software or redesigning the workflow. Without that event, “temporary” is merely a label on permanent access.

Pilot the awkward cases first

Where the platform supports an observation or low-impact mode, use it to identify devices and likely policy outcomes before enforcement. Observation is evidence gathering, not proof that every blocked path is safe. Service owners still need to explain essential dependencies.

Expand by a bounded location or device group. Keep a known-good configuration, a support contact and an agreed stop condition. Track failed joins by cause so certificate problems do not become a collection of broad network bypasses.

Choose outage behaviour deliberately

Fail-open and fail-closed approaches each have consequences. Unrestricted continuity may undermine the access policy; denying every new connection may stop essential work. Define the required behaviour by device group and location, including any restricted continuity network, and test what the chosen platform actually does.

Separate new authentications from existing sessions and reauthentication events. Their behaviour can differ. Document the dependencies that must remain reachable for recovery, including management and certificate services, without opening unrelated paths.

The handover should contain the device inventory, policy map, exception register, certificate lifecycle, outage results and support runbook. Use the same acceptance evidence during a wireless infrastructure refresh. Network access control is ready to expand when operations can explain both a permitted connection and a refusal, and can resolve either without improvising access.