Network Access Control: Deciding Who and What Gets On

The problem: any device, any port, full access

Walk through most offices and you can still find the original sin of enterprise networking — a live Ethernet jack in a conference room, a lobby, or an unused cubicle that will hand an IP address to anything you plug into it. That port does not ask who you are. It does not ask whether the laptop is corporate-managed, patched, or even hostile. It simply switches the frame and lets the device onto the same layer 2 fabric as your file servers and domain controllers.

The device population making that assumption dangerous has changed. It is no longer just employee laptops. It is contractor machines, personal phones, IP cameras, badge readers, HVAC controllers, VoIP handsets, label printers, and a steadily growing fleet of IoT hardware that ships with weak firmware and hardcoded credentials. The Verizon Data Breach Investigations Report continues to show that lateral movement — not the initial foothold — is what turns a single compromised device into a company-wide incident. Network Access Control (NAC) is the discipline that decides, at the moment of connection, whether a device gets on at all and, if so, what it is allowed to reach.

How 802.1X authenticates a port before it opens

The backbone of modern NAC is IEEE 802.1X, which authenticates a device before the switchport moves out of an unauthorized state. Three roles are involved:

• Supplicant — the software on the endpoint (built into Windows, macOS, Linux, and mobile) that presents credentials.
• Authenticator — the switch or wireless controller enforcing the policy at the edge.
• Authentication server — a RADIUS server that makes the actual decision, almost always tied back to your directory.

Credentials travel inside an EAP (Extensible Authentication Protocol) method, and the method you choose matters. EAP-TLS uses a client certificate on each device and is the gold standard: there is no password to phish or spray. PEAP wraps username and password authentication in a TLS tunnel — easier to deploy, but only as strong as the passwords behind it. For a greenfield rollout aimed at zero trust implementation, certificate-based EAP-TLS is the target; PEAP is a common transitional step.

Figure: the port stays closed until the RADIUS server authorizes the device — authentication happens before an IP address is ever issued.

The obvious gap: not everything runs a supplicant. A ten-year-old badge reader has no idea what EAP is. For those devices, MAC Authentication Bypass (MAB) lets the switch fall back to authenticating by hardware address against an allow-list. MAB is useful and unavoidable, but a MAC address is trivially spoofable, so it should never be treated as strong identity. It is a way to recognize a dumb device, not to trust it — which is exactly why profiling matters next.

Profiling the devices that can't identify themselves

Because so much of the network is unmanaged and unauthenticated, NAC has to figure out what a device is by observing it. Good profiling combines several signals:

1. DHCP fingerprinting — the pattern of options a device requests often uniquely identifies its OS or hardware class.
2. MAC OUI — the vendor prefix reveals whether you are looking at an Axis camera, a Cisco phone, or a Raspberry Pi.
3. LLDP/CDP and switch data — neighbor discovery and the port a device lives on add context.
4. Active scanning — a light NMAP-style probe or HTTP banner grab confirms open services and firmware.

The output is a classification: "this is an IP camera," "this is a Windows domain laptop," "this is an unknown BYOD phone." That classification is what lets you write policy for the IoT and OT devices that cause the worst incidents but can never run an agent. When the classifier is confident a device is a badge reader, you can confine it to a narrow role automatically instead of trusting a spoofable MAC.

Posture: authenticated is not the same as healthy

A valid login from a neglected, malware-ridden laptop is still a compromise. For managed endpoints, NAC can check posture — the device's security state — as a condition of access:

• Operating system patch level within policy
• Disk encryption enabled
• A running, up-to-date endpoint protection or EDR agent
• Required configuration present, prohibited software absent

Devices that fail posture do not have to be dropped cold. A well-designed policy routes them to a remediation VLAN with access only to patch and update servers, lets them fix themselves, and re-evaluates. This turns NAC from a blunt gate into a self-service enforcement mechanism that keeps unhealthy machines away from production without generating a help-desk ticket for every stale patch.

Dynamic segmentation: the real payoff

Authentication and profiling are only interesting because of what the RADIUS server can return along with its "accept." Instead of a static port configuration, the policy engine sends back attributes that place the device into the right context on the fly:

• Dynamic VLAN assignment (via the Tunnel-Private-Group-ID attribute) drops the device into the correct network segment regardless of which jack it used.
• Downloadable ACLs push a per-session filter onto the port.
• Security Group Tags (SGTs) carry identity-based policy across the fabric so enforcement follows the device, not the IP.

This is where NAC stops being an authentication checkbox and becomes the enforcement arm of your segmentation strategy. The camera lands in a locked-down IoT segment, the contractor laptop in a restricted zone, the finance workstation in its own protected context — all decided at connect time, all consistent whether the user is in headquarters or a branch office. Extending that same policy uniformly across sites is far easier when it is designed into how we build global networks rather than bolted on per location. NAC gives your network security program a way to enforce least privilege on the wired and wireless edge, not just at the perimeter firewall.

Guest and BYOD onboarding without a ticket

The same infrastructure solves the perennial guest-Wi-Fi problem. A captive portal intercepts unauthenticated devices and offers a controlled onboarding path:

• Self-registration for visitors, with time-limited internet-only access and client isolation so guests can never route to internal resources.
• Sponsored access, where an employee approves a guest, creating an audit trail.
• BYOD onboarding that provisions a certificate or a device-specific credential so personal phones get a defined, limited role instead of a free pass.

Done right, this eliminates the shared Wi-Fi password taped to the reception desk and the "guest" network that quietly still resolves internal DNS.

Roll it out in monitor mode before you enforce

NAC has a well-earned reputation for locking people out of the network on go-live day. The failure mode is always the same: enforcement is switched on before anyone understands the real device population. The fix is a phased rollout.

1. Deploy in monitor (open) mode. The switch authenticates and logs every device but permits traffic regardless of the result. You learn what is actually connected — including the forgotten devices no inventory shows — with zero user impact.
2. Build and validate policy. Use the collected data to write authentication, profiling, and posture rules, and confirm the exceptions (that one legacy PLC, the conference-room codec) are handled.
3. Enforce low-risk segments first. Flip guest and printer VLANs to enforcement before touching user access.
4. Enforce broadly, keep a fallback. Move to closed mode with a documented break-glass path so a RADIUS outage never becomes a site outage.

Rushing from step one to step four is how NAC projects strand a company for months. Running the sequence patiently is how they succeed quietly.

NAC as the LAN's zero-trust enabler

Zero trust is usually discussed in terms of identity, cloud apps, and remote access — the places without a traditional perimeter. But the local network is where the "trusted inside" assumption is most dangerous and most persistent. NAC is what extends never trust, always verify down to the physical port and the SSID. Every device proves who it is, proves it is healthy, and receives only the access its role requires, re-checked at every connection.

That is the LAN half of a zero-trust architecture, and it is often the missing half. intSignal designs and operates NAC the way it should be done: discovery and monitor mode first, profiling tuned to your actual device fleet, and enforcement tied to real segmentation policy instead of a vendor default. If you want a clear picture of what would happen the next time an unknown device plugs into an open port in your environment, talk to our team.