Open the show run on a floor switch and look for two things: how many RADIUS servers are actually configured, and what deadtime they carry. That is what your network will do the day the policy engine stops answering. The default value of radius-server deadtime on IOS and IOS XE is 0.
Cisco documents it with the consequence attached. If deadtime is not specified it defaults to 0, "which brings the server back to the UP state right away", and that is why "the RADIUS server state could flap, causing additional authentication issues". In practice: the switch takes a while to mark a server dead, because it needs both criteria — a minimum time since the last valid response and a number of consecutive timeouts — and the moment it marks it, it revives it. On the next authentication it asks the very same server that is still restarting. The other server, the one that is up, only gets the request after the first exhausts its retries, if it gets there at all. Two configured servers plus deadtime 0 make one server with a queue.
That detail has been sitting there for years and hardly ever bothers anyone. This week it does, because a lot of people have to restart their ISE nodes in a hurry.
The advisory
Cisco published cisco-sa-ISE-ABP-VNSW7Tn5 on 16 September, version 1.0 and already marked final. CVE-2026-76460, CVSS 10.0, vector AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H, CWE-648. The cause, literally: "insufficient authentication control on an API endpoint". It affects Identity Services Engine and the Passive Identity Connector on branches 3.1, 3.2, 3.3, 3.4 and 3.5, and is fixed in 3.1 Patch 12, 3.2 Patch 11, 3.3 Patch 12, 3.4 Patch 7 and 3.5 Patch 4. If you are on 3.0, the advisory table offers you no patch: it says that branch has reached End of Software Maintenance and that you should migrate to a supported release that includes the fix. There are no workarounds. And the PSIRT states it is aware of active exploitation.
CISA added it to the known exploited vulnerabilities catalog that same 16th, in version 2026.09.16, under directive BOD 26-04 and with the forensic triage flag. Three CVEs went in that day, all three due on 19 September: this one, the Acronis backup plugin permissions flaw we wrote about this morning and a cellular modem flaw in Google Pixel devices. The 19th falls on a Saturday, so the last working day is tomorrow.
The access.log comes before the patch
The part of the advisory that got almost no coverage yesterday is the indicators of compromise section, and it is the one that changes the order of your tasks. Cisco says that to confirm any attempted exploitation you have to review the access.log and look for suspicious usernames, and it tells you where to look. Below it comes the paragraph worth reading twice: after successful exploitation, attackers may obtain "command execution with root privileges", and precisely because of that level of access "evidence of exploitation and indicators of compromise may be removed or hidden by the threat actors". Hence the recommendation to cross-check network and firewall logs outside the affected device.
And it goes all the way, which is what hardly any vendor writes down: if malicious activity is suspected, the strong recommendation is to re-image the node and restore the configuration from backup. It is the same conclusion we reached with Cisco's firewall manager a few days ago, except there we were the ones saying it and here the vendor signs it. It also explains why CISA flagged this entry for forensic triage.
What we do not know is how it is being exploited. Cisco publishes no technical detail of the attack nor the date from which it has been observed, and anyone giving you the exploit step by step today is making it up. What has been published is enough to order the work: read the log before touching anything, patch, and decide what you do if the log has something in it.
Why a 10 and not a 9.8
Almost every remote authentication bypass tops out at 9.8. This one reaches 10 because of one letter: S:C, scope changed, which in CVSS means the vulnerable component and the impacted one are not the same. The advisory itself tells you what that crossing is a few paragraphs down: what gets bypassed is the web management interface's authentication, and what is obtained is command execution as root. The whole box, not the application.
The score stops there, because CVSS does not score downstream damage. Downstream damage is what will take up your afternoon, and for that it helps to separate two things that get confused. The firewall manager we wrote about a few days ago is a management plane: it is consulted when somebody wants to change something. ISE has one just like it, and it is also something else: a real-time decision plane, on the critical path of every 802.1X authentication, every printer MAB and every VPN authorisation. It is asked thousands of times a day, whenever somebody plugs in a cable. A decision plane can be stolen, and it can also be switched off. The second is the one that is almost never decided.
The patch rolls, if you have somewhere to fall
What holds back patching a network access control system is a reasonable fear: leaving the office unauthenticated for the length of the window. For a distributed deployment, the vendor has an answer. Cisco writes it like this: "Cisco ISE installs the patch on the primary node first, then proceeds to the secondary nodes". If it fails on the primary it does not proceed to the secondaries; if it fails on a secondary, it moves on to the next; and each node reboots when its own installation finishes. The prerequisite the manual notes is leaving the PAN auto-failover checkbox unchecked for the duration. What the documentation does not promise anywhere is that two secondaries will not overlap: you check that yourself, with a test node or with a clock.
Now the part that appears in no guide, because it describes a good share of our customers: in a thirty-person office, ISE is not a distributed deployment. It is one machine, or two. Nothing rolls there. When the only node answering authentications restarts, there is no second one to fall back on, and everything after this paragraph stops being a configuration nuance and becomes the whole question.
The two modes you decide, and the third you already have
When the server does not answer, a port with 802.1X enabled behaves in one of these three ways. Two of them are decisions. The third is usually a leftover.
- Closed. No server, no authorisation. The Catalyst documentation describes it without embellishment: without the bypass, "the client attempts and fails authentication indefinitely, and the switch port remains in the spanning-tree blocking state". It is what happens by default as soon as you enable 802.1X, because the default configuration table ships "Inaccessible authentication bypass: Disabled". Safe and expensive: the laptop that boots does not get in, and neither does the printer that rebooted.
- The second is inaccessible authentication bypass, also called critical authentication or the AAA fail policy: if the server does not respond, the switch puts the port into the critical-authentication state. For a device not yet authorised, in the VLAN you configured; but for one that was already authorised and comes up for reauthentication, the guide warns it stays "in the current VLAN, which might be the one previously assigned by the RADIUS server". That is, the one ISE handed it, not necessarily the one you picked. When the server returns you can have critical ports reinitialise their hosts and reauthenticate them.
- And then there is the port carrying
authentication open, where traffic flows even if authentication has not completed or nobody answered. It is a documented, legitimate feature: it is how you roll out 802.1X without breaking the office on day one, and how you monitor before enforcing. It is also the state an uncomfortable number of deployments settle into, because somebody turned it on to stop the tickets, it worked, and nobody turned it off. If that is your case, this week's CVSS 10 changes little on your switches: your access control was already in permanent degraded mode.
None of the three is the right one in the abstract. A hospital and a laboratory do not want the same thing, and a plant floor with production scanners does not want the same thing as a thirty-person office. What is not defensible is not knowing which one you are in.
One honest caveat, because it changes the arithmetic and explains the title. Sessions that are already authenticated survive the server going away: the Catalyst guide says ports that are already authenticated and do not have periodic reauthentication enabled "remain in the authenticated state" and that "communication with the RADIUS server is not required". And periodic reauthentication also ships disabled by default. A patch at three in the morning, with the office empty, will probably go unnoticed — and that is why your network's failure mode has gone years without review. The choice was never made because it was never needed. It only shows itself when the outage and somebody trying to get in coincide; almost never in testing.
That is why we are careful with the easy diagnosis. The reason people say out loud for delaying a NAC patch is the maintenance window, and the maintenance window is usually the cheap part, because you choose it. The expensive one is the other: the one somebody else chooses. Anyone able to take down your policy engine's availability does not need to bypass your access control at half past nine on a Tuesday; it is enough to force you to decide in the heat of the moment, with the phones ringing, between locking the staff out and opening the door. It is redundancy that exists in the diagram and does not survive the procedure, again.
The order we would follow
The log first, and this is what changes compared with a normal patch. Before restarting anything, review the access.log on every node in the deployment looking for usernames you do not recognise, as the advisory indicates. If something turns up, the patch stops being the end of the job and becomes the beginning: the vendor's recommendation is to re-image that node and restore its configuration. And since execution is with root privileges, the indicators may have been wiped from the inside; the logs that really count are the ones outside the box, on your firewall and your collector.
Then the patch, with the patch number and not the branch number. "We are on 3.3" is not an answer: the reference points are 3.1 P12, 3.2 P11, 3.3 P12, 3.4 P7 and 3.5 P4, and on 3.0 there is no patch, there is a migration. Check the Passive Identity Connector too, which is on the affected list and gets forgotten because nobody calls it "the ISE". And while you are there, the question AV:N raises: from which network is that admin interface reachable. It has no reason to be reachable from user VLANs, from the guest VLAN, or from the internet.
And then, at your own pace, the part that outlives this CVE. Count in the show run — not in the diagram — how many servers each switch sees, and set a deadtime that is not zero, consistent with how long one of your nodes takes to restart. Decide whether you want probing with automate-tester, understanding the trade: without probe-on it probes constantly, detects the outage before a user pays for it, and in exchange sends steady traffic at the server; with probe-on it probes only once the server is marked dead, so it does not save the first user but recovers the server without waiting for the deadtime to expire. Either beats the factory value, which is having neither.
That leaves the inventory that decides all of the above and that hardly anyone consults before choosing: the devices that come in through MAB with nobody behind them. Printers, cameras, scanners, door access, the machine on the plant floor, the phones. When they are locked out they do not open a ticket: they go quiet, and that is why the cost of closed mode shows up in no support statistic. And with that list in front of you, the last step: shut down a node on purpose on a Tuesday at ten and watch what happens on a real port, with a real laptop. It is the step that meets the most resistance and the only one that produces certainty; we do it with everything we consider critical, for the same reason we time our restores. A plan nobody has rehearsed is an intention in document format.
Which mode is your network in right now?
We design Zero Trust architectures where authorisation does not run out once you cross the door, and we operate the networks and communications underneath: VLANs, policies, RADIUS, the failure mode chosen on purpose and the drill that proves it. We are not Cisco resellers, nor resellers of any access control vendor, so what you decide does not change our invoice. And if your access control is already well built, we will tell you so and sell you nothing.
Talk to everyWANOne idea is left, and it is our opinion: a NAC is not Zero Trust. An 802.1X setup that authenticates the port and then drops the machine into a flat VLAN is still a perimeter, just moved to the floor wiring closet. The symptom gives it away: if authorisation still meant something after crossing the door, the door's degraded mode would matter a good deal less than it does. It is the same argument we made about treating the identity provider as just another application: the piece that decides cannot live in the same bucket as the pieces it decides about. And for the record, ISE does well a job many attempt and few manage; insufficient authentication control on an API endpoint turns up in products of every size, and this month has already had a few.
Note on sources
All consulted on 17 September 2026. One: Cisco advisory cisco-sa-ISE-ABP-VNSW7Tn5, published 2026-09-16 as version 1.0 final, source of the CVE, the CVSS 10.0 and its vector, CWE-648, the sentence on insufficient authentication control on an API endpoint, affected branches 3.1 to 3.5 including ISE-PIC, the fixed patches, the note that 3.0 has reached End of Software Maintenance and must be migrated, the absence of workarounds, the PSIRT's awareness of active exploitation, and the whole indicators of compromise section: reviewing the access.log for suspicious usernames, the quotes on command execution with root privileges and on indicators possibly being removed or hidden by threat actors, the recommendation to cross-check network and firewall logs external to the device, and the recommendation to re-image the node and restore the configuration if malicious activity is suspected. Two: CISA's known exploited vulnerabilities catalog, version 2026.09.16, read from its JSON: the three entries added on 2026-09-16 (CVE-2026-76460 Cisco ISE, CVE-2026-87886 Acronis Backup and CVE-2026-58704 Google Pixel), all three due 2026-09-19 and flagged for forensic triage, under directive BOD 26-04. That the 19th falls on a Saturday is calendar arithmetic. Three: Cisco ISE upgrade guides (branches 3.1 and 3.3), source of the literal sentence on the primary-then-secondaries order, the behaviour on failure at the primary or a secondary, each node rebooting when its own install completes, and the requirement to leave the PAN auto-failover checkbox unchecked. That the documentation does not promise non-overlapping restarts between secondaries is our reading of what those guides do not say, and is stated as such. Four: the Cisco support article "Understand AAA Dead Detection and Deadtime on IOS XE" and the command reference for radius-server deadtime, source of the default value of 0, both literal quotes on the immediate return to the UP state and on flapping, the two dead-marking criteria, and the behaviour of automate-tester with and without probe-on. Five: the Catalyst security configuration guides (9300 and 1000): the description of inaccessible authentication bypass as critical authentication or the AAA fail policy, the critical VLAN behaviour for an unauthorised port and the warning that reauthentication of an already-authorised port uses the current VLAN, host reinitialisation when the server returns, the sentence on what happens without the feature — the client fails indefinitely and the port stays in the spanning-tree blocking state — the default 802.1X configuration table with "Inaccessible authentication bypass: Disabled" and periodic reauthentication disabled, and the section on already-authenticated ports, which remain authenticated without requiring communication with the RADIUS server. The existence of authentication open as a deployment mode is a documented Cisco feature; that an uncomfortable share of deployments settles there is our observation, not a measured figure. It is also our opinion, stated as such, that a NAC is not Zero Trust and that the maintenance window is the cheap part of the problem. We do not know how this flaw is being exploited and we do not claim to.
Microsoft 365
ES 
CAT 
EN