On September 9, 2026, Cisco PSIRT published an advance notification stating that security advisories for Identity Services Engine, Secure Firewall, Nexus Dashboard, BroadWorks and ThousandEyes would publish on September 16. Seven days later the batch landed — 32 advisories covering 79 CVEs, of which 15 advisories and 42 CVEs were against ISE alone. Three of the ISE advisories carry a base score of 10.0.
One of those three is CVE-2026-76460, an authentication bypass in an ISE API caused by insufficient authentication control on an endpoint. Cisco found it while resolving a TAC support case, and the advisory's Exploitation and Public Announcements section states that PSIRT "is aware of active exploitation of this vulnerability." CISA added it to the KEV catalog the same day with a due date of September 19.
Three days to remediate. Every outlet that covered it started the clock on the 16th.
Why three days was never the real constraint
Cisco moved to this model in July. Security-hardened releases publish on the first and third Wednesday of each month, and seven days before each one PSIRT publishes the list of technologies and platforms included. Cisco stated the purpose plainly in its announcement: the notice exists "so you can pre-stage change windows, lab validation, and maintenance approvals."
That matters here because the fix for CVE-2026-76460 is not a patch you apply — it is a patch level. ISE 3.1 needs Patch 12, 3.2 needs Patch 11, 3.3 needs Patch 12, 3.4 needs Patch 7, 3.5 needs Patch 4. ISE 3.0 has no fixed release at all; it has reached End of Software Maintenance, so remediation there is a migration to a supported train. There are no workarounds. Cisco's only mitigation is an infrastructure ACL restricting management and control plane traffic destined to the device.
And ISE is the appliance that decides whether anything on the network is permitted to authenticate. Taking it through a patch level means RADIUS stops answering for the duration, which is why that change lives behind a named business owner and a multi-week approval in most organizations rather than a Tuesday evening. The bottleneck was never learning the CVE number. It was convening the window. Under BOD 26-04, the median KEV deadline fell from 21 days to 3, and three days does not buy a first approval meeting. Seven does not either — but seven plus three does, if the window was already provisionally on the calendar.
The practice: schedule against the cadence, not the CVE
Put the first and third Wednesday of every month on the change calendar as a standing provisional maintenance window for the Cisco estate, and subscribe to the advance notification advisory so the preceding Wednesday is a decision point. On notice day you know which technologies are in the drop. If ISE is named, you start approval and lab validation with seven days of runway and a window already booked, so publication day is a go/no-go rather than a request.
The cost is real and worth stating: you will reserve outage windows on authentication infrastructure that you then cancel most months. Cancelling a booked window costs a calendar invite. Convening one from a standing start against a three-day federal deadline costs an emergency change board, and frequently costs the deadline. The notice is also explicit that the schedule "is not a final commitment of releases" — products may be removed, rescheduled, or added when releases are ready early — so provisional is the right word. Treat it as a heads-up, not a work order.
When the upgrade genuinely cannot happen inside the window — a 3.0 deployment with nowhere to go, or a train you have not lab-validated — the iACL is the fallback, and it is a change on the upstream devices rather than on ISE. That means it needs no ISE outage and can be staged independently of the upgrade. It is also a question you can answer today without waiting for anything: whether the ISE management interface is reachable from a user VLAN at all is determined by ACLs you already own.
What to check this week
- The release and patch level on every ISE and ISE-PIC node, compared against the fixed level for its train. A distributed deployment is only as patched as its least-patched node.
- Whether a host on a user VLAN can open the ISE admin interface. If it can, the mitigation Cisco recommends is not in place.
show logging application ise-kong/access.logon every node, looking for unfamiliar usernames. Cisco notes that successful exploitation yields root, and that an attacker at root can remove the evidence — so cross-check firewall and network logs off the appliance for unexpected outbound transfers.- Whether anyone currently receives the advance notification. If your first knowledge of a Cisco advisory batch comes from a news headline, you are working with three days instead of ten.
- If exploitation is suspected, Cisco's instruction is to re-image the affected nodes and restore from configuration backup — the same rebuild-rather-than-upgrade distinction Cisco drew for Secure Email Gateway days earlier. Upgrading a compromised node produces a patched compromised node.
North InfoSec runs AI-assisted penetration testing and security assessments, including testing whether management interfaces are reachable from the segments that are not supposed to reach them. northinfosec.com