EAP-TLS Failures, CoA That Does Nothing, and Unsegmentable PSK Devices

Frame it as a differential Both wings use the same WLAN, same ISE cluster and same renewed server certificate, so the difference must be in something that varies by client or by path. Enumerate and test:

1. Certificate chain presented to the client. A renewed server certificate issued without the intermediate CA appended will fail on clients that do not already have the intermediate cached. West-wing laptops may have picked it up from a GPO or OS update; east-wing laptops with an older image may not. Test with openssl s_client -connect <psn>:443 -showcerts against both PSNs and confirm the full chain, and compare the failing and working laptop trust stores.
2. Which PSN the client reaches. Check the RADIUS server configuration and any DNS or load-balancer steering. If east-wing clients are steered to a PSN whose certificate was not renewed, or to one whose new certificate name does not match the profile's expected server name, only that population fails. Read the ISE 12514 detail for the PSN identity.
3. Supplicant capability. Older east-wing builds may have TLS 1.0/1.1 only, or a supplicant that does not accept the new key size or signature algorithm. Compare the client supplicant policy and OS build between a passing and a failing laptop.
4. Time skew and client certificate state. A renewed server certificate with a not-before date in the future relative to a skewed laptop clock produces a handshake failure. Check client clock and the client certificate validity window.

Distinguishing tests

• Move one failing laptop to a west-wing AP: if it still fails, the problem is the client; if it succeeds, the problem is the path or the PSN steering.
• Take an ISE packet capture for one failing and one passing session and compare the server certificate presented and the alert code.
• Confirm whether the failure count tracks a specific PSN or a specific laptop image.

Do not disable server certificate validation on the clients as a fix.

First, separate the two possible failures The CoA may not be reaching the controller at all, or it may be reaching it and the VLAN change may not be applied. They have different fixes.

CoA not applied

• RFC 5176 CoA must be sent to the controller's reachable address (the active management address). In an HA SSO pair, pointing ISE at the standby address or at a stale NAD entry means the CoA is silently dropped.
• Verify the shared secret matches the NAD definition and that UDP 1700 is permitted between ISE and the controller.
• Check the controller's client detail for the CoA/re-authentication counter and the ISE CoA audit log for a NAK.

CoA delivered but VLAN unchanged

• VLAN assignment from RADIUS requires AAA override to be enabled on the WLAN (and where applicable on the policy profile). Without it, the returned VLAN attribute is logged and ignored, which fits "stays in the old VLAN" exactly.
• A VLAN change only takes effect at association. A CoA-Request that performs a re-authentication does not move the client; you need the client to reassociate, which typically means a CoA terminate (disconnect) plus reauthentication, or the client's own roaming. ISE posture policies should be written accordingly.
• If the WLAN is FlexConnect with local switching, confirm the VLAN is mapped in the FlexConnect policy and that the local VLAN exists at the branch.

The one-hour detail An hour smells like session timeout rather than CoA: the client eventually reassociates for an unrelated reason. Validate by watching a single client's state transitions during a CoA test.

Fix summary Correct NAD address and secret, enable AAA override, use terminate-and-reconnect for VLAN moves, and test with one clinical laptop before a fleet-wide policy push.

Set expectations on MAC filtering first MAC filtering is an inventory and nuisance control, not a security control: the MAC is transmitted in the clear in every frame and is trivially spoofed. It also breaks on device replacement and creates an operational burden. State plainly that segmentation done with one shared PSK plus MAC filtering is a flat trust domain; anyone with the key is on every floor's network.

Options

1. iPSK without RADIUS. Multiple PSKs on a single WLAN. This gives per-floor or per-vendor keys and lets you retire a key without a site-wide outage, but check your release's PSK limit and confirm whether per-PSK VLAN assignment is supported without an external server; if it is not, you get key separation without true L3 segmentation.
2. iPSK with ISE. ISE returns the PSK and the VLAN/ACL attributes, so each pump group lands in its own VLAN. This is the cleanest fit for "segment by floor" without changing pump configuration beyond the key, and it keeps AAA override and CoA available for later.
3. Separate WLAN per floor. No external dependency, but SSID proliferation, more beacons, and awkward client provisioning; usually only acceptable for two or three groups.
4. Replace or gateway the pumps. Where the vendor offers an 802.1X-capable model or a medical device security gateway, prefer that for the long term.

Recommendation Option 2 if ISE is already deployed and licensed; option 1 as an interim if the pumps cannot be re-keyed quickly. In both cases keep the pump traffic on its own VLAN with an ACL limiting it to its clinical application servers, and monitor for new MACs rather than trusting the filter to keep people out.