A compromised network access control (NAC) policy server decides which devices get onto your network and where they land, and it holds the RADIUS shared secrets, certificates and directory credentials that every switch, wireless controller and supplicant trusts. This playbook covers suspected or confirmed compromise of a NAC or RADIUS policy platform: the policy servers, their administration console, profiling and posture services, guest portals and integrations. It is vendor-neutral and based on the IETF RADIUS and EAP specifications, the CERT/CC note on the 2024 RADIUS protocol flaw, NIST incident response guidance and the Five Eyes joint advisory on incident handling. It is for network engineers, identity teams and incident responders. How NAC works is covered in the Network Access Control (NAC) Guide; hardening is covered in Securing the network access control (NAC) itself.
Key takeaways
- Decide fail-open or fail-closed before you touch anything. Every switch and controller has a behaviour when the policy server is unreachable, and containment that triggers it can either lock out the hospital ward or open every port.
- The shared secrets are the crown jewels. Whoever holds a RADIUS shared secret can impersonate the server to that network device, so every secret on a compromised server must be replaced on both ends.
- The server certificate is a credential too. With the EAP server's private key, an attacker can run a convincing rogue access point and harvest credentials from supplicants that trust it.
- Policy is evidence. Changed authorisation rules, VLAN assignments, MAC bypass lists and posture exceptions show what the attacker wanted, and must be reviewed line by line.
- Rebuild with modern transport. Recovery is the moment to require Message-Authenticator, move to RADIUS over TLS where supported, and retire MS-CHAPv2 based methods.
What a NAC platform holds
| Asset | Used for | What an attacker can do with it |
|---|---|---|
| RADIUS shared secrets (one per network device or group) | Authenticating RADIUS packets between switches, controllers and the server; obfuscating User-Password | Impersonate the server to network devices, forge Access-Accept, recover PAP passwords from captured traffic |
| EAP server certificate and private key | Proving the server to supplicants in EAP-TLS, PEAP and EAP-TTLS | Run a rogue authentication server or access point that supplicants accept (ATT&CK T1557 Adversary-in-the-Middle) |
| Directory bind or join account | Looking up users, groups and machines; validating MS-CHAPv2 challenges | Directory reconnaissance and, depending on rights, credential attacks |
| Authorisation policy | VLAN assignment (Tunnel-Private-Group-ID, RFC 3580), downloadable or named ACLs (Filter-Id), session timeouts | Place attacker devices in privileged VLANs, widen ACLs, exempt devices from posture |
| MAC authentication bypass lists and profiling data | Admitting printers, phones, cameras, medical and OT devices without supplicants | Add spoofable MAC addresses to trusted groups (T1200 Hardware Additions) |
| Change of Authorization (CoA) clients | Disconnect-Request and CoA-Request on UDP 3799 (RFC 5176) | Disconnect or re-authorise sessions at will |
| Integration credentials | API keys and accounts for device management, endpoint security, SIEM and firewall identity feeds | Pivot into those platforms or feed them false identity data; see the NAC integration security guide |
| Guest and sponsor portal accounts | Self-service and sponsored guest access | Create long-lived guest access or harvest portal credentials |
How the compromise shows up
| Signal | Where to look | Likely meaning |
|---|---|---|
| Admin logons from unusual hosts, new admin accounts or role changes | NAC admin audit log, directory logs | Console takeover (T1078, T1098) |
| Authorisation rules, VLAN mappings or MAC bypass entries changed outside change control | Policy change history, configuration diff against backup | Attacker shaping access for their devices |
| Access-Accepts for unknown endpoints into privileged VLANs | RADIUS accounting and authentication logs | Rogue devices admitted |
| Spike in CoA or Disconnect messages, or from a new source | Network device logs, NAC CoA logs | Disruption or session manipulation |
| Supplicants reporting certificate prompts or new server certificates | Help desk tickets, endpoint logs | Rogue EAP server using a stolen or new certificate |
| Exploitation advisory for your NAC platform version | Vendor bulletins, CISA Known Exploited Vulnerabilities catalogue | Assume compromise if exposed while unpatched |
| Export of configuration or certificate stores | Admin audit log, file integrity monitoring | Theft of secrets and keys for later use |
Triage questions
- What was reached? The admin console only, the operating system of a policy node, the certificate store, or the configuration database where shared secrets live.
- Which EAP methods are in use? EAP-TLS with client certificates exposes less than PEAP or EAP-TTLS with passwords. MS-CHAPv2 exchanges captured by an attacker can be attacked offline.
- Is RADIUS traffic protected in transit? If it crosses untrusted or shared networks as plain RADIUS/UDP, CERT/CC VU#456537 (CVE-2024-3596) applies: an attacker on the path can forge responses where Message-Authenticator is not required.
- What is the fail behaviour on each network device class? Critical authentication VLAN, open port, or closed port when servers are unreachable.
- Which integrations hold credentials? List API keys and accounts towards device management, endpoint security, firewalls and SIEM.
- Which device populations cannot re-authenticate easily? Medical, building and OT devices on MAC bypass often need on-site work if their policy changes.
Containment by priority
The Five Eyes joint advisory warns against preemptive credential resets and against fixes that tip off the attacker before the scope is known. For NAC this matters twice: replacing shared secrets in a hurry can break authentication across the estate.
- Preserve evidence. Export the configuration, policy history, admin audit log and RADIUS logs to storage outside the platform. Image policy nodes if the operating system may be compromised.
- Lock down administration. Restrict console and API access to a privileged access workstation path, disable unknown admin accounts, and revoke integration API keys you do not need during the incident.
- Freeze policy. Stop all policy changes except by the response team. Revert malicious authorisation and MAC bypass changes from a reviewed backup copy.
- Quarantine suspicious endpoints. Use CoA to move unknown endpoints admitted during the incident into a restricted VLAN, or shut the switch ports they use after recording their location.
- Stand up a clean policy node if needed. If a node is compromised at operating system level, build a new node from vendor media, load the reviewed policy, and point network devices at it with new shared secrets, one device group at a time. Keep the old node isolated for analysis.
- Protect RADIUS transport. Restrict UDP 1812, 1813 and 3799 to known network device and server addresses, and require Message-Authenticator on Access-Request where devices support it.
Fail-open or fail-closed
| Option | Effect during containment | Use when |
|---|---|---|
| Fail-closed | New connections are refused while servers are unreachable | Office and data centre access where availability can wait and rogue access is the bigger risk |
| Critical VLAN | Devices land in a restricted VLAN with limited access | Most estates; gives users basic service while blocking sensitive segments |
| Fail-open | Ports allow traffic without authentication | Only for life-safety or production devices, on segments isolated by other controls |
Secret, key and credential rotation
| Order | Item | How | Caution |
|---|---|---|---|
| 1 | NAC administrators and integration API keys | Reset, phishing-resistant MFA, new keys with least privilege | Integrations break until updated; plan the order |
| 2 | EAP server certificate and private key | Issue a new certificate under a new key, revoke the old certificate, push trust to supplicants | RFC 9190 requires peers to check revocation, but many supplicants do not; if the old certificate chains to a dedicated CA, consider removing that CA from supplicant trust |
| 3 | RADIUS shared secrets | New unique secret per network device or small group, at least 16 octets as RFC 3580 suggests, changed on both server and device | Roll by device group with the change window and console access ready |
| 4 | Directory bind or join account | New account or password, minimum rights, rejoin nodes | Machine-account based joins need the node rejoined |
| 5 | User passwords used with PEAP or EAP-TTLS during the incident | Reset for users whose exchanges could have been captured or relayed | Prioritise privileged users and those seen on rogue access points |
| 6 | Guest and sponsor accounts | Expire all active guest accounts and reset sponsor access | Communicate to front desks |
Certificate replacement at scale is covered in the CA Compromise and Mass Certificate Replacement Playbook, and supplicant trust settings in the 802.1X and EAP-TLS Enterprise Wi-Fi Guide.
Eradication and rebuild
- Policy nodes: Rebuild from verified vendor media at a patched version rather than cleaning in place. Restore policy from a reviewed text export, not a full system backup that may carry attacker accounts.
- Policy content: Review every authorisation rule, VLAN mapping, ACL, MAC bypass entry and posture exception against business owners. Remove anything without an owner.
- Endpoints admitted during the incident: Locate them by switch port and access point, physically inspect unknown devices, and check for rogue hardware (T1200) and network bridging (T1599).
- Network devices: Confirm that RADIUS server definitions, CoA clients and local fallback accounts on switches and controllers were not changed (T1556.004 Network Device Authentication covers attacker changes to device authentication).
- Transport: Where supported, move to RADIUS over TLS (RFC 6614), noting RFC 9765 RADIUS/1.1 is Experimental. The IETF draft "Deprecating Insecure Practices in RADIUS" (draft-ietf-radext-deprecating-radius-10, July 2026, not yet an RFC) proposes that RADIUS/UDP must not be used outside secure networks and that new clients must not implement MS-CHAP based methods; treat it as direction, not a finished standard.
Recovery and validation
- Pilot one site or device group with the rebuilt nodes, new secrets and new certificate, and monitor authentication failure rates.
- Validate: Confirm old shared secrets are rejected, the old certificate is no longer presented anywhere, unknown endpoints are gone from privileged VLANs, and integrations use new keys.
- Roll out by group, moving device classes back from critical VLAN or fail-closed to normal policy.
- Rollback: Keep the previous device configuration ready to restore per group if authentication fails, but never with the old secrets or the old certificate. The safe fallback is the critical VLAN, not the compromised server.
- Heightened monitoring for 30 days on admin changes, MAC bypass additions and Access-Accepts into privileged VLANs.
Evidence to preserve
- NAC platform: Admin audit log, policy change history, configuration exports from before and during the incident, certificate store listings, node disk and memory images.
- RADIUS logs: Authentication and accounting records with calling station ID (MAC), NAS identifier and port, assigned VLAN and policy matched.
- Network devices: Logs of RADIUS server changes, CoA messages received, port up and down events, and current configuration.
- Wireless: Rogue access point detections and client association history.
- Physical: Photos and location of any unknown devices found on ports, handled with chain of custody; see the Evidence Handling and Chain of Custody Guide.
Notification triggers
A NAC compromise on its own may not expose personal data, but captured user credentials and admitted rogue devices often lead to wider access. Assess whether personal data was accessed: under UK and EU GDPR Article 33, reportable personal data breaches go to the supervisory authority within 72 hours of awareness where feasible. Entities in scope of NIS2 must give an early warning within 24 hours of becoming aware of a significant incident. Check sector rules and contracts, and record when you became aware.
Detection and measurement
- Secret uniqueness: share of network devices with a unique RADIUS shared secret, target 100%.
- Message-Authenticator enforcement: share of network devices and server policies requiring it.
- Unowned policy entries: number of authorisation rules and MAC bypass entries without a named owner, target zero.
- Time to quarantine: minutes from detection of an unknown endpoint to CoA quarantine.
- Admin change alerting: share of policy changes outside change control that raise an alert.
Framework mapping
| Activity | NIST CSF 2.0 | NIST SP 800-53 Rev. 5 | MITRE ATT&CK |
|---|---|---|---|
| Triage and scoping | RS.MA-02, RS.AN-03 | IR-4, IR-5 | T1078, T1098 |
| Endpoint quarantine and policy freeze | RS.MI-01 | IR-4, SC-7 | T1200, T1599 |
| Secret and certificate rotation | PR.AA-01, PR.AA-03 | IA-3, IA-5, SC-12 | T1557, T1040 |
| Node rebuild and device configuration check | RS.MI-02 | CM-2, CM-3 | T1556.004 |
| Recovery and validation | RC.RP-01, RC.RP-03 | CP-10, SC-8 | n/a |
| Monitoring | DE.CM-01 | SI-4, AU-6 | n/a |
Common failure patterns
- One shared secret everywhere. A single secret across hundreds of switches means one theft compromises the whole estate and rotation becomes a programme.
- Rotating secrets on the server only. Devices still hold the old secret, authentication fails, and teams roll back to the compromised value.
- Keeping the old EAP certificate trusted. Supplicants keep accepting a rogue server using the stolen key because revocation is not checked.
- Reverting to fail-open under pressure. An outage pushes teams to open all ports, which gives the attacker exactly what they wanted.
- Ignoring MAC bypass lists. Policy is reviewed, but spoofable MAC entries added during the incident stay in place.
- Leaving default or hard-coded credentials on network devices. The 2025 access point hard-coded credentials flaw showed how a fixed admin credential on network access hardware can undo the policy server's work.
Practitioner checklist
- Document fail behaviour for every network device class and agree it with business owners.
- Use a unique RADIUS shared secret per device or small group, stored in a secrets manager.
- Issue the EAP server certificate from a dedicated CA, and configure supplicants to check the server name.
- Keep a reviewed text export of policy off the platform, and diff it after every change window.
- Require Message-Authenticator and restrict RADIUS and CoA ports to known addresses.
- Inventory integration API keys and accounts, with owners and least privilege.
- Alert on MAC bypass additions and Access-Accepts into privileged VLANs for unknown endpoints.
- Exercise a policy node rebuild and a shared secret rotation for one site each year.
Standards and references
- IETF: RFC 3580, IEEE 802.1X RADIUS Usage Guidelines
- IETF: RFC 5176, Dynamic Authorization Extensions to RADIUS
- IETF: RFC 9190, EAP-TLS 1.3
- CERT/CC: VU#456537, RADIUS protocol susceptible to forgery attacks
- IETF: Deprecating Insecure Practices in RADIUS (Internet-Draft)
- NIST: SP 800-61 Rev. 3, Incident Response Recommendations and Considerations for Cybersecurity Risk Management
- Canadian Centre for Cyber Security with CISA, NCSC and partners: Technical Approaches to Uncovering and Remediating Malicious Activity
- NIST: SP 800-53 Rev. 5
Related NHI Mgmt Group resources: Network Access Control (NAC) Guide · Securing the network access control (NAC) itself · RADIUS Security Guide · Layer 2 Attacks Guide