The device that most needs profiling, the silent, agentless one, is exactly the device closed mode never lets you profile. Here is how Arbiter fixes that, without opening the port to anything but DHCP.
Closed-mode 802.1X will not let a device pass DHCP until after it has authenticated. But an unknown, non-802.1X device (a printer, a camera, a sensor) has nothing to authenticate with except its MAC, and a bare MAC tells you almost nothing. So you cannot profile it, which means you cannot write a policy for it, which means you can only reject it. That is the chicken and egg situation many of us deploying NAC encounter. Opening the port to fix it exposes the network. Arbiter's answer is a third option: admit the unknown device into a locked holding role that permits DHCP and nothing else, let the DHCP exchange profile it, then reauthenticate it into its real policy automatically the moment it is classified. Default-deny is preserved throughout. The only endpoint traffic permitted during profiling is DHCP.
You cannot protect what you cannot see, and you cannot see what you cannot let speak
Network access control has an awkward dependency at its centre. To apply the right policy to a device you need to know what the device is. To know what it is you need to observe it: the DHCP options it asks for, the hostname it advertises, the services it announces. And to observe any of that, the device first needs enough network access to send those packets.
For a laptop or a phone this is fine. It runs an 802.1X supplicant, it proves an identity with a certificate or credentials, and it earns full access. Profiling is a nice-to-have on top.
The problem is everything else. Printers, IP cameras, door controllers, building sensors, medical devices, industrial kit. Most of it has no supplicant and never will. For those devices the only lever the switch has is MAB, MAC Authentication Bypass: the switch reads the source MAC off the port and hands it to the RADIUS server as the identity.
A MAC address is a weak identity. The first three bytes (the OUI) hint at a manufacturer, and manufacturers reuse and randomise them, so even that is soft. The MAC does not tell you whether this is a printer or a PLC. So on the very first sighting of an unknown device you have almost nothing to base a policy on.
Why closed mode creates this issue
In closed mode, the switch port stays shut until RADIUS returns an Access-Accept. No ordinary endpoint traffic such as DHCP or ARP flows before authentication. This is the correct default posture: a port does not carry traffic for a device the network has not vetted.
Now trace the loop for an unknown MAB device:
- Device links up. Port is closed. Nothing flows.
- Switch does MAB, sends the MAC to Arbiter.
- Arbiter has never seen this MAC. It has no profile, so no class, so no policy match beyond “unknown”.
- With closed mode and a deny-by-default stance, the only safe verdict is Access-Reject.
- Port stays closed. The device never gets to DHCP.
- Because it never DHCPs, it is never fingerprinted, so it is never profiled, so the loop gives the same answer forever.
The device that most needs profiling (the silent, agentless one) is exactly the device closed mode never lets you profile. DHCP fingerprinting, one of the richest and cheapest profiling signals there is, is unreachable because DHCP is on the far side of the very gate profiling is supposed to open.
"Just let some traffic flow first" is not the answer
The obvious shortcut is to let some traffic flow before authentication completes. In fully open or monitor deployments, that may mean meaningful network access for an unknown endpoint. Low-impact deployments reduce that exposure with a pre-authentication ACL, but the permitted access is statically defined on the switch and exists before RADIUS has made a decision.
Arbiter keeps the port closed until RADIUS explicitly authorizes the endpoint into a DHCP-only holding role. The exception is therefore part of the authorization decision, not a standing pre-authentication allowance on every port. A statically open pre-auth ACL applies to every device that links up, profiled or not, wanted or not. A holding role applies only to the specific endpoint RADIUS chose to place there, only for as long as it takes to profile it, and only for the one packet class profiling needs.
That distinction matters when authentication stalls or the control plane is slow. A pre-auth allowance that was meant to be transient becomes a standing exposure the moment the decision behind it is delayed. A holding role has no existence independent of an authorization decision, so there is no “temporary” state left hanging when something upstream is slow.
The third option: a DHCP-only holding role
The trick is to stop treating “unknown” as a synonym for “reject”. An unknown device does not need full access to be profiled. It needs exactly one thing: the ability to complete a DHCP exchange. So give it that, and nothing else.
Instead of returning Access-Reject for an unknown MAB endpoint, Arbiter returns Access-Accept into an Unprofiled Endpoints authorization:
- A DHCP-only ACL on the port. Permit UDP 67 and 68 to the DHCP infrastructure (and the broadcast the discover needs), deny everything else. No lateral traffic, no gateway, no internet. This is enforced through the standard RADIUS Filter-Id attribute, referencing a DHCP-only ACL pre-staged on the NAD. The policy intent remains consistent across vendors, while the local ACL syntax is handled by the appropriate switch template.
- A Session-Timeout with Termination-Action = RADIUS-Request, so that when the timer expires the switch reauthenticates the session rather than tearing the port down. With CoA driving the fast promotion (below), this timer is the backstop, not the primary path, so it does not need to be aggressive: the example profile below uses 600 seconds.
You build this holding role as an ordinary Arbiter access profile: result Access-Accept, a Filter-Id naming your DHCP-only ACL, and a Session-Timeout with Termination-Action = RADIUS-Request. A Tier-2 access policy then routes unprofiled endpoints to it. Nothing about it is a special code path: it is the same profile machinery every other role uses, pointed at one deliberately narrow ACL.
The same flow in three moves.
First, initial authorization into the holding role. The unknown MAC hits the port, the switch does MAB, and because Arbiter has no profile it accepts the endpoint into the Unprofiled Endpoints role rather than rejecting it. The DHCP-only ACL and the reauth timer come down in that Access-Accept, and the port opens for DHCP and nothing else.
Second, profiling and classification. The device DHCPs, and the access VLAN forwards that relay traffic to Arbiter Edge alongside the production DHCP service, so Edge reads option 55, option 60 and option 12 without becoming the lease authority. Fingerbank uses those signals to infer a likely device class, and the endpoint record updates from unknown to, say, an “Axis network camera” or a “Brother laser printer”.
Third, reauthorization into final policy. That classification can trigger an automatic CoA (see the next section), so the switch presents the same MAC to policy again. This time Arbiter matches a profiled endpoint to its class-based rule and returns the real authorization: the camera VLAN, a printer ACL, quarantine, whatever the rule says. The holding role was transient scaffolding that existed only for one DHCP exchange.
DHCP is a good exception to make because it is narrow and well understood. The holding-role ACL permits only the client-server DHCP ports, only towards the DHCP infrastructure, and denies the rest by default. A device in this role cannot scan the subnet, cannot reach the gateway, cannot touch another endpoint, and cannot reach the internet. If it is compromised, the reachable attack surface is constrained to the DHCP infrastructure, where DHCP snooping, client rate limiting and the usual infrastructure protections still apply.
It also matches how these devices behave. A printer or a camera DHCPs the instant its link comes up, with no user interaction, so the profiling window opens on its own. You are not waiting on a human to log in. The device is never fully exposed: default-deny holds the entire time, and the single exception carved out of it is the exact packet class profiling needs.
The promotion trigger: an automatic CoA, with a timer backstop
Promotion is automatic. When a scan or a DHCP discovery classifies a device that was previously unprofiled, that classification is itself a trigger, so Arbiter has the endpoint presented to policy again straight away and it leaves the holding role for its class-based policy without anyone touching it. In the product this is the endpoint-classified CoA action, and like every trigger it is configurable per tenant under Endpoints, CoA Actions.
Arbiter sends a reauthorization or reauthentication CoA appropriate to the NAD. Where the NAD supports RFC 5176 Authorize-Only, Arbiter can request a fresh authorization decision for the existing session. On platforms that expose a separate host-reauthentication action, it uses the supported reauthentication mechanism instead. In both cases the endpoint is presented to policy again after its profile has been updated: Arbiter dispatches the CoA once the updated endpoint profile has been committed, so the fresh decision always sees the settled classification rather than racing the fingerprint write.
The reauthentication timer is the backstop for NADs that cannot or do not act on CoA. It uses Session-Timeout with Termination-Action set to RADIUS-Request, which RFC 3580 describes as the signal to reauthenticate when the session timer expires, and it depends on nothing vendor-specific. Because the classification CoA is doing the real promotion, this timer can stay relaxed (the example profile uses 600 seconds) and only matters when CoA is unavailable. As with any dynamic authorization feature, validate the exact NAD behaviour during deployment.
What the device (and the operator) actually experiences
From the device's point of view: link up, get a lease, wait a moment, and (in the common case where promotion keeps the endpoint on the same VLAN) land on the network. Most agentless devices do not notice, because they were only ever going to DHCP and then start their real work, which simply begins a few seconds later than it otherwise would.
From the operator's point of view: an unknown device appears in Arbiter almost immediately as an unprofiled endpoint in the holding role, self-populates with a class as soon as it DHCPs, then moves into its proper group on its own, because Arbiter has it reauthorized the moment it is classified. You watch a device profile itself, in closed mode, without ever having opened the port to anything but DHCP.
Honest caveats
- The holding-role ACL has to exist. You pre-stage a named ACL that the Filter-Id points at. This is a one-time piece of switch templating.
- A DHCP fingerprint is a classification signal, not proof of identity. DHCP options can be copied or deliberately spoofed, so a device class should not automatically grant broad or sensitive access by itself. Arbiter can combine the fingerprint with other evidence such as OUI, known inventory, SNMP data, observed services, MDM status or an operator approval. Where DHCP classification is used for automatic authorization, the resulting policy should remain narrowly scoped and least-privileged.
- Promotion that changes VLAN needs a fresh DHCP cycle. The device gets its lease while in the holding authorization. Where promotion changes the endpoint's VLAN, the NAD and endpoint must initiate a fresh DHCP cycle, because the original lease is no longer valid on the new segment. Some embedded devices respond correctly to the authorization change, while others may require a disconnect-style CoA or a session restart. RFC 5176 supports both changing an existing authorization and disconnecting a session, but the resulting enforcement behaviour is implemented by the NAD. Arbiter therefore validates VLAN-transition behaviour per NAD type, or can retain the existing VLAN and change only the endpoint ACL where that is the more reliable design.
- A device that never sends useful DHCP stays unprofiled. That is the correct failure mode. It remains in the DHCP-only holding role rather than being promoted on a guess. Fail closed, not open. Other Arbiter signals (a passive multicast announcement, an SNMP or nmap sighting) can still enrich it in parallel, which is why we run several profiling sources rather than leaning on DHCP alone.
- This is for MAB, not for user devices. A laptop should be doing 802.1X with a real identity, not being profiled into access. The holding role is for the silent, agentless population where MAC is the only lever.
- Timer tuning is a real dial. Too short and you generate reauth noise. Too long and promotion drags. Pair it with CoA where you can, so the timer only matters as a backstop.
Closed mode without the blindness
The usual framing pits security against visibility: run closed mode and stay blind to your silent devices, or run open mode and see everything at the cost of exposure. The DHCP-only holding role dissolves the trade. You keep deny-by-default and the closed-mode posture, and you still profile the devices that closed mode would normally keep you blind to, because you granted them exactly one capability (DHCP) and revoked it the moment it had done its job.
You cannot protect what you cannot see. It turns out you can see it without letting it loose, if you are precise about the one packet you let through.