Compliance-gated 802.1X access
Build a wired 802.1X policy that does more than permit or deny. Certificate-holding laptops that Intune reports as compliant land on your trusted VLAN. The same laptops when non-compliant drop to an Internet-only quarantine instead of being kicked off the network, so a lapsed device can still self-remediate without a helpdesk ticket.
What you will build
This guide walks through a real wired 802.1X policy end to end. The shape is deliberately simple and is the pattern most SMEs should start from:
- Compliant laptops get full access. A device that presents a certificate from your Arbiter tenant root and that Intune currently reports as compliant is permitted onto your trusted data VLAN.
- Non-compliant laptops get the internet, nothing else. The same trusted device, when Intune flags it non-compliant, is still let onto the network but pinned to an Internet-only access list. It can reach DNS, DHCP and the public internet to pull updates or re-run a compliance check, but it cannot see a single internal host.
- Everything else is denied. Anything that is not a recognised, certificate-holding device never matches a permit rule and falls through to the default deny.
Before you start
- An Arbiter tenant with the Edge appliance online and at least one switch already authenticating against it. If not, start with the Edge appliance guide and the network device guides.
- EAP-TLS working for at least one device, with certificates issued from your tenant root, and the Intune compliance sync enabled so the
mdm_compliantfield is populated. The Intune integration guide sets up both halves. - A trusted data VLAN your compliant devices should land on. We use VLAN 21 throughout as the example.
- CLI or controller access to the switch, so you can add one named ACL for the quarantine path.
How Arbiter evaluates a policy
Arbiter policies are ordered. Each incoming authentication is tested against your rules from the top down, and the first rule that matches wins. If nothing matches, the request hits the default deny at the bottom. Two concepts do all the work:
- Conditions are the tests. Each is a field, an operator and a value, for example
mdm_compliant equals "Yes". Combine several with AND and every one must be true for the rule to match. - Profiles and actions are what happens on a match. A profile can permit with a VLAN, permit with an access list, deny, or Continue, which means "this rule is a gate, carry on evaluating the rules nested beneath it".
The policy in this guide uses a parent Continue rule to scope everything to wired 802.1X, then two profile rules nested underneath it: one for the compliant case and one for the non-compliant case. The Hits counter next to each rule in the portal shows how many live authentications matched it, which is the fastest way to confirm a new rule is doing what you think.
The fields used below are all populated automatically once EAP-TLS and the Intune sync are running:
| Field | What it is |
|---|---|
auth_method | How the device authenticated. dot1x for EAP, mab for MAC Authentication Bypass. |
Port Type | The medium the request came in on, ethernet for wired or wireless for Wi-Fi. |
cert_issuer | The common name of the CA that signed the client certificate. For Arbiter-issued certs this is your tenant root, shown under Settings -> Certificate. |
mdm_compliant | The current Intune compliance verdict for the device, Yes or No, refreshed every MDM sync cycle. |
Scope the policy to wired 802.1X
Start with a parent rule that catches only wired EAP traffic, so the compliance logic underneath never accidentally applies to Wi-Fi or to MAB devices like printers. In the portal go to Policies -> + New rule, name it Wired 802.1x and set the action to Continue.
| Setting | Value |
|---|---|
| Name | Wired 802.1x |
| Condition | Port Type equals "ethernet" |
| Condition (AND) | auth_method equals "dot1x" |
| Action | Continue |
| Status | Enabled |
On its own this rule permits nothing. It is a gate: any wired 802.1X request matches it and then flows into the two profile rules you add next. Everything that is not wired 802.1X skips the whole group.
Permit compliant laptops onto the trusted VLAN
Nested under the parent rule, add the happy path. Name it Wired Laptops, match on both the certificate issuer and the compliance verdict, and permit with your data VLAN.
| Setting | Value |
|---|---|
| Name | Wired Laptops |
| Match type | profile |
| Condition | cert_issuer equals "<your-tenant>-root" |
| Condition (AND) | mdm_compliant equals "Yes" |
| Profile / action | Permit + VLAN 21 |
| Status | Enabled |
Send non-compliant laptops to quarantine
Add a second profile rule beneath the first, for the same trusted devices when Intune reports them non-compliant. Instead of a VLAN it applies an Internet-only access profile, which you build in step 4.
| Setting | Value |
|---|---|
| Name | Wired Laptops Non-compliant |
| Match type | profile |
| Condition | cert_issuer equals "<your-tenant>-root" |
| Condition (AND) | mdm_compliant equals "No" |
| Profile / action | Internet Only |
| Status | Enabled |
Build the Internet-only access profile
The quarantine rule points at an access profile that returns an Access-Accept with two extra attributes. In the portal create an access profile named Internet Only:
| Attribute | Value | Why |
|---|---|---|
| Result | Access-Accept | The device is allowed on, just constrained |
Filter-Id | INTERNET_ONLY.in | Tells the switch to apply its named ACL to inbound traffic on the port |
Session-Timeout | 300 | Forces the device to re-authenticate every 300 seconds, so a return to compliance is picked up within a few minutes |
Filter-Id is the standard RADIUS attribute (number 11) for naming a filter the network device should enforce. On Cisco IOS the .in suffix tells the switch to apply the ACL in the inbound direction. The value before the suffix, INTERNET_ONLY, must match the ACL name you define on the switch in the next step exactly.
Define the INTERNET_ONLY ACL on the switch
Arbiter names the filter, the switch enforces it. Create a named extended ACL whose name matches the Filter-Id value. This example is Cisco IOS, but the same shape applies to any vendor that supports Filter-Id, see the per-vendor network device guides for the exact syntax.
ip access-list extended INTERNET_ONLY
! Let the device get an address and resolve names
permit udp any eq bootpc any eq bootps
permit udp any eq bootps any eq bootpc
permit udp any any eq domain
permit tcp any any eq domain
! Allow basic reachability diagnostics
permit icmp any any echo
permit icmp any any echo-reply
permit icmp any any unreachable
permit icmp any any time-exceeded
! Block all internal ranges so quarantined devices cannot reach the LAN
deny ip any 10.0.0.0 0.255.255.255
deny ip any 172.16.0.0 0.15.255.255
deny ip any 192.168.0.0 0.0.255.255
deny ip any 169.254.0.0 0.0.255.255
deny ip any 224.0.0.0 15.255.255.255
! Everything left is the public internet
permit ip any anyThe ACL reads top to bottom and does four things in order:
- Allow DHCP and DNS so the device can get an address and resolve names. Without these the quarantine looks like a dead network.
- Allow basic ICMP diagnostics (echo, unreachable, time-exceeded) so connectivity tests and path MTU discovery still work.
- Deny every internal range, the RFC 1918 private blocks plus link-local and multicast. This is the line that makes it Internet-only: a quarantined device cannot reach a single host on your LAN.
- Permit everything else, which by this point is only the public internet.
Verify with a real device
Plug a compliant, enrolled laptop into an 802.1X port. In the Arbiter portal open Auth Log and you should see a Permit with Method DOT1X, EAP Type TLS, the device's certificate common name and the Wired Laptops rule credited with the hit. The device lands on VLAN 21 with full access.
Now flip that same device to non-compliant in Intune (for a quick test, a compliance policy that requires a setting you can toggle off works well) and let the next MDM sync run. Within one sync cycle plus the 300 second session timer, the device re-authenticates and the Wired Laptops Non-compliant rule takes the hit instead. From the device you should now be able to reach a public site and resolve DNS, but a ping to any internal host should fail.
Principles for good 802.1X rules
Start in monitor mode
Before you enforce anything, run the policy in monitor mode (or point your switch ports at it with open authentication) and watch the Auth Log for a few days. You will see exactly which devices would have been denied or quarantined, and catch the surprise printer or badge reader before it locks someone out.
Scope narrowly, permit narrowly
Each permit rule should name the specific things that make a device trustworthy, the certificate issuer and the compliance state here, rather than permitting broadly and trying to deny the exceptions. A rule that permits little and a default that denies everything else is far easier to reason about than the reverse.
Prefer quarantine to deny for known devices
A hard deny is right for an unknown device. For a device you enrolled that has simply drifted out of compliance, a constrained Access-Accept keeps it productive enough to fix itself and keeps the failure off your helpdesk queue. Keep the quarantine path genuinely limited though: Internet plus the bare minimum to recover, never a quieter route onto the LAN.
Re-authenticate often on the constrained path
A short Session-Timeout on quarantine rules is what turns "fix your device" into a self-service action. Full-access sessions can run long, but anything constrained should re-check frequently so a recovered device is promoted quickly and a newly broken one is contained quickly.
Read the Hits counters
After any change, the per-rule Hits counter is your ground truth. A rule sitting at zero hits is either dead weight or in the wrong order. A catch-all quarantine rule taking far more hits than you expected usually means a condition above it is too tight.
Where to go next
- Extend the same pattern to Wi-Fi by adding a parallel rule group scoped to
Port Type equals "wireless", reusing the same compliance conditions. - Wire the certificate and compliance plumbing this guide assumes with the Intune integration guide.
- Ship every Permit, quarantine and deny verdict into your SIEM with SIEM forwarding so the access decisions are auditable alongside the rest of your security data.