The breach was three alerts. Nobody connected them.

Picture three tickets in your queue, opened over three different weeks, closed by three different analysts who never spoke to each other.

The first: an authentication anomaly on an SD-WAN controller. Odd, but it resolved, and the controller kept running. Closed. The second: a new SSH key showed up in an admin account's authorized-keys file. Probably the network team during a maintenance window. Closed. The third: a configuration change pushed out to the edge devices. That's literally what the platform is for. Closed.

Each one, on its own, was a shrug. Together, they were a threat actor walking from the open internet to root on your network's management plane — and then pushing their will to every device downstream.

The chain Cisco documented this month

This isn't hypothetical. On June 5, 2026, Cisco disclosed its seventh SD-WAN zero-day of the year. Read the advisories together and they describe an end-to-end path, link by link:

• CVE-2026-20127 — get in A maximum-severity authentication bypass on the Catalyst SD-WAN Controller. An unauthenticated, remote attacker sends crafted requests and gains high-privileged internal access. Cisco Talos has tracked a sophisticated actor, UAT-8616, abusing this since at least 2023.
• CVE-2026-20182 — get privileged A second authentication bypass lets the attacker become an authenticated peer of the appliance and inject their own public key into the vmanage-admin account's authorized SSH keys. That's the quiet alert in the middle: a key that shouldn't be there. They now hold netadmin.
• CVE-2026-20245 — get root With netadmin in hand, a crafted file upload to the SD-WAN Manager CLI runs arbitrary commands as root. Cisco observed exploitation in the wild — discovered by Mandiant — and, in limited cases, a configuration change pushed to edge devices. There is no patch yet and no workaround.

Cisco's advisory for that last bug explicitly names the first two as the way to obtain the netadmin precondition. The vendor itself drew the line connecting the dots. The question is whether your SOC would have.

A breach is almost never one alert. It's a sequence — across systems, across privilege levels, across time. Attackers think in chains. Most defenses still triage in singletons.

Why three real alerts read as three non-events

None of these links trips a five-alarm fire on its own. The first is an "authentication anomaly" — a category your team sees hundreds of times a week, almost all benign. The second is a configuration-file change on an admin account — indistinguishable, at a glance, from legitimate operations. The third, the root-level one, scores a moderate 7.8 and surfaces as a routine config push, which is the platform's entire job.

So they land in different queues. The controller alert goes to whoever owns network infrastructure. The SSH-key change goes to whoever watches identity. The config push may not alert at all. Three people, three contexts, three independent "looks fine to me" decisions. The correlation that turns three shrugs into one breach never happens, because no single human is holding all three at once.

This is the coverage gap that volume created. It isn't that analysts are careless — it's that the breach only exists in the relationships between alerts, and human triage is structurally built to look at one alert at a time.

Totality is the answer to chains

You don't close this gap by tuning any single detection to be louder. The controller bypass should be a low-confidence alert in isolation. So should an SSH-key change. Crank them all to critical and you've simply moved alert fatigue, not fixed it.

You close it by investigating everything and correlating across the whole estate — so the relationship between a Tuesday auth anomaly, a Thursday key injection, and a Friday config push is computed, not hoped for. Nothing missed. Every alert investigated, every alert connected to every other one it touches.

That's what we mean by totality. Not "we alert on more things." It's that no alert is ever evaluated alone — each one is enriched, scoped, and cross-referenced against everything else happening on your network, including the quiet things that closed last week.

How n0limit sees the chain as one incident

When the controller authentication anomaly hits n0limit, it's investigated and given a verdict in microseconds — and retained as context, not closed and forgotten. When the SSH key appears on vmanage-admin days later, it isn't a standalone curiosity: it's automatically correlated with that earlier anomaly on the same management plane, and the combined picture is escalated. By the time a config push reaches the edge, the platform is already presenting one incident — not three tickets — with a reasoning trail an operator can audit end to end: here's the entry, here's the privilege escalation, here's the root action, here's the blast radius.

The analyst doesn't have to be the one who remembers that an unrelated-looking alert fired eleven days ago in a different queue. The correlation is the machine's job. The judgment is still the operator's.

Attackers will keep chaining — it's the most reliable tradecraft they have, because they know defenders are watching the links and missing the chain. The only durable answer is a SOC that holds every alert at once and refuses to evaluate any of them in isolation. See the chain, and a breach stops being a surprise assembled from things you already knew.