Network access control has a reputation for causing outages, and the reputation is earned. The product is installed, enforcement is switched on, and by mid-morning the printers are offline and somebody senior cannot get on the network.
The technology is rarely at fault in that story. Enforcement was switched on before anyone knew what was plugged in. This guide sets out the order I do it in instead. The principles are vendor-neutral. The product I work with is FortiNAC, on an estate that spans a Premier League football club’s stadium and training ground, where disruption on a match day is not an option.
Network access control does two jobs, in this order:
Most of the value in the first months comes from the first job. Many organisations have never had a complete, current list of what is on their network, and control is only as good as that list.
Every network that has been running for a few years contains things nobody documented: a switch under a desk, a door controller, a display screen, a device installed by a contractor. A policy written from the documentation covers the devices people remember. Enforcement applies it to the devices that are actually there, and each undocumented one becomes a support call.
The fix is to separate the two jobs in time. Run visibility on its own until the list stops surprising you, and bring in control in small steps after that.
NAC sits on top of the switching and authentication you already have. If those are inconsistent, it will be too. I check four things first, usually as part of a wider network security audit.
Every switch and wireless controller, with model, firmware version, management address, location and what its uplinks connect to. NAC products talk to switches directly, and feature support depends on model and firmware. Check each one against the NAC vendor’s current compatibility documentation.
NAC places devices into segments, so the segments have to exist and mean the same thing everywhere. A workable plan for most organisations separates:
The same VLAN should carry the same purpose at every site, and the rules between segments should be written down and enforced on the firewall. Without that, moving a device from one VLAN to another achieves very little.
The NAC system needs to read from and write to the switches. That means management access configured consistently: SNMPv3 in place of the older unencrypted versions, syslog sent to a known collector, time synchronised and individual administrative logins. Small configuration differences are a common reason a rollout works in one building and misbehaves in the next.
Two methods do most of the work, and they are not equivalent.
802.1X is real authentication. The device proves its identity, ideally with a certificate issued by your own certificate authority and delivered by a management tool such as Intune. It is the right method for managed laptops, desktops and phones. It needs a working RADIUS service and a certificate process, and the device has to support it.
MAC authentication bypass (MAB) is for devices that cannot do 802.1X. The switch presents the device’s MAC address and the RADIUS or NAC system decides what to do with it. It works with almost anything. Its weakness is that a MAC address can be copied, so treat MAB as a way to recognise a device and put it in a restricted segment. It should never be a route to the corporate network.
The NAC system is connected to the switches and wireless, and does nothing except watch. It builds a list of every device it sees and where it is connected, and it profiles each one: what kind of device it appears to be, based on signals such as the manufacturer prefix of the MAC address, how it requests an address and how it behaves on the network.
Nothing changes for users in this phase. How long to run it depends on the organisation. It needs to cover a full cycle of normal activity, including whatever happens only occasionally: month-end, an event, a maintenance visit. Devices that connect once a month are the ones locked out later if this phase is cut short.
This is where the project succeeds or fails.
The aim is that when enforcement arrives, every device is already in the segment the policy would put it in.
By the end of phase 2 you should be able to fill in a table like this for your own estate.
| Device type | Authentication | VLAN / segment | Enforcement approach |
|---|---|---|---|
| Managed laptops and desktops | 802.1X with device certificates | Corporate | Enforce early; failures go to a restricted remediation segment |
| Managed phones and tablets | 802.1X on corporate Wi-Fi | Corporate or mobile | Enforce with the wireless rollout |
| Printers | MAB plus profiling | Printers | Registered in advance; firewall limits them to print traffic |
| CCTV and door control | MAB plus profiling | CCTV / physical security | Registered in advance; no route to user networks |
| Operational technology and AV | MAB, sometimes fixed port assignment | OT / building systems | Enforce last, with the system owner present |
| Guest devices | Guest portal or sponsored access | Guest | Internet only, isolated from internal segments |
| Contractor laptops | Sponsored, time-limited registration | Contractor or guest | Access limited to the systems they are there to work on |
| Unknown devices | None | Isolation | No access until identified; alert raised |
Enforcement starts with the smallest, best-understood part of the network: the IT team’s own floor, or one building. I work through the same steps each time:
Exceptions are normal. Each one should be deliberate, recorded and as narrow as possible.
Some organisations have times when network disruption is unacceptable. For a venue it is an event day, and for a retailer it is peak trading. Build change freezes into the plan from the start: no new enforcement, no policy changes and no switch firmware updates inside the window.
The freeze also shapes the visibility phase. Devices that appear only during an event, such as temporary equipment or a broadcast partner’s kit on its own VLAN, need to be seen and classified before any policy touches the ports they use.
NAC decisions improve when they use more than the network’s own view. A firewall can report that a device is behaving badly, and an endpoint management or security agent can report whether a laptop is compliant. The NAC system can respond by moving the device to a restricted segment. What is available depends on your products and licences, so check the vendor documentation. Introduce automated responses as cautiously as enforcement, because a quarantine triggered by a false positive is an outage too.
Send the logs somewhere they will be read. NAC events, RADIUS authentication results and firewall logs belong in a SIEM such as Microsoft Sentinel, alongside identity and endpoint logs, so an investigation follows one timeline. This is part of the wider infrastructure and security picture, and the case studies describe an estate where it was built that way.
A NAC deployment that nobody tends will degrade into a list of exceptions. Agree these before the project closes:
Done in this order, the day enforcement is switched on should pass without anyone outside IT noticing.
I design and deploy network access control as part of wider Fortinet and network security work: audit first, visibility before enforcement, and documentation someone else can run. Utilis is independent and does not resell hardware or licences. Get in touch or book a 30-minute call and bring your network diagram.
Book a Free Discovery Call