Your security tools are identity infrastructure, and September's attackers treated them that way

Four of September 2026's most serious incidents started in products whose job is to protect or manage other systems. Two Cisco consoles, an MSP management platform and a third-party security product at a crypto exchange were all exploited. The vulnerabilities differed. The consequence was the same each time: the attacker inherited the credentials and authority the product held over everything else. That makes these products identity infrastructure, and it changes what "we patched it" should mean.

Four incidents, one shape

Cisco Secure Firewall Management Center. Attackers exploited a CVSS 10 authentication bypass in FMC to get root, then ran tooling that queried the console's internal database for user authentication data and credentials. A separate cluster used a second FMC flaw for initial access before deploying Qilin ransomware. A firewall console holds the directory integrations that authenticate VPN users, and often RADIUS and LDAP bind credentials.

Cisco Identity Services Engine. A week later, Cisco confirmed exploitation of a CVSS 10 ISE bypass that gives an unauthenticated attacker root. ISE is the engine that decides which users and devices get onto the network, and it stores the shared secret for every switch and wireless controller that asks it.

N-able N-central. A pre-authentication remote code execution flaw in the MSP platform, and a chain that creates an attacker-controlled System Administrator account, arrived as the fourth hotfix in five weeks. An administrator in N-central is an administrator at every customer it manages.

Bitget. The exchange lost about $388 million after an attacker exploited a zero-day in a third-party security product, reached an internal management system, and issued withdrawals using legitimate administrator credentials. Private keys were never touched, because the management plane could instruct the wallet service directly.

Why these products are tier zero

Identity teams already accept that some systems are tier zero: the domain controllers, the identity provider, the PKI. Compromise one of those and you can become anyone. The products in this list meet the same test, even though they are usually owned by network, security operations or MSP teams rather than identity teams.

They meet it in two ways. First, they hold credentials for other systems: bind accounts, shared secrets, API keys and agent credentials, stored so the product can do its job. Root on the console is a credential harvest. Second, they hold authority that other systems obey: a network access decision, a remote command to every managed endpoint, a withdrawal instruction. The attacker does not need to break those downstream systems. The downstream systems do what the console tells them.

That is why "patched" is not the end of these incidents. Patching closes the way in. It does nothing about the credentials already read, the administrator accounts already created, or the sessions already issued.

What to do differently

Classify them as tier zero and govern them that way. Put every management console, RMM platform, NAC server and security product with broad access on the same list as your identity provider. That means privileged access through a PAM workflow, phishing-resistant MFA for every administrator, and no standing administrator accounts where just-in-time access will do.

Isolate the management plane. None of these interfaces needs to be reachable from the internet or from ordinary user networks. For the ISE flaw, Cisco's only mitigation short of patching was to restrict management traffic with access lists. That restriction should be the permanent state, not an emergency measure.

After patching, run an identity response. For each product, list the secrets it held and rotate them: directory bind accounts, RADIUS shared secrets, API keys, agent credentials, local administrator passwords. Enumerate administrator accounts and tokens created since the exposure window opened, not since the patch, because an account created before the fix survives it. Revoke sessions issued through the product. This is credential manager key extraction applied to an appliance, and it needs the same response.

Separate authority from access. Bitget's fix was to add independent withdrawal checks. The general principle is separation of duties: a high-impact action, whether a large withdrawal, a mass software push to managed endpoints, or a change to network access policy, should require approval through a channel that an administrator session on the same console cannot reach.

Watch what the console does, not just what runs on it. The Qilin operators used FMC's own built-in tooling for reconnaissance, and Bitget's attacker looked like an administrator. Detection that looks for malicious binaries sees nothing. Baseline the administrative actions each console normally takes, alert on new administrator accounts and bulk configuration changes, and treat test-sized actions just under an alert threshold as a signal rather than noise.

What this does not mean

It does not mean these vendors are uniquely careless. Every product with a management interface and stored credentials has this shape, and more of them will be exploited. The point is ownership. When the product sits outside the identity program, nobody asks what it holds, what it can command, or what must be rotated after it is compromised. Bringing it inside the program is what turns the next exploited console from a breach into a contained incident.

Related reading

• Credential manager key extraction and static API key abuse
• RADIUS, separation of duties and zero standing privileges in the glossary
• This Week in Identity, Issue 14 and Issue 15
• PAM vendors