Expert Opinions

They Didn’t Hack Your Endpoints. They Hacked Your Controller

Written by:
Brendan Sullivan
Brendan Sullivan
Published on:
July 2, 2026
They Didn’t Hack Your Endpoints. They Hacked Your Controller

The cybersecurity industry spent a decade solving the wrong problem.

We consolidated. We centralized. We built unified management consoles, cloud policy engines, SaaS identity brokers: one pane of glass for thousands of devices. The pitch made operational sense: reduce complexity, enforce everything from one place, give security teams visibility across the entire environment.

It was elegant. It was efficient. And it handed sophisticated adversaries a single key to the entire kingdom.

The pattern is consistent. It has been for more than five years.

State-sponsored actors do not attack networks at random. They attack the highest-leverage target available. And for the past decade, the highest-leverage target has been the centralized management controller. Compromising one means owning everything it governs.

I’ve spent years working with teams that build and operate mission-critical networks. The lesson from every one of these campaigns is the same: the attack is on the controller, not the endpoints. The industry built the most efficient target in the history of enterprise security, and sophisticated actors noticed.

SolarWinds Orion in 2020: a trojanized software update gave Russia’s SVR simultaneous access to 18,000 organizations across government, defense, and critical infrastructure through one trusted management platform. Fortinet FortiOS in 2022 through 2024: persistent administrative access to U.S. government and enterprise networks worldwide via a single management plane vulnerability. Ivanti Connect Secure in 2024: authentication bypass at the device whose explicit purpose was to enforce Zero Trust access, before any user-level check could occur. VMware vCenter: every virtual machine a hypervisor managed, owned through a single management console. Cisco IOS XE: 50,000 network devices compromised in 48 hours through one web UI vulnerability. Volt Typhoon’s OT campaign: CISA confirmed five-plus-year persistent access to U.S. critical infrastructure by targeting the IT/OT management corridor specifically.

Not a single endpoint. Every target is a management platform. Concentrated management authority creates concentrated risk. The incentive is rational and the track record is clear.

The second problem only surfaces when the stakes are highest

Even if the target problem were solved, a second architectural failure is embedded in every cloud-managed Zero Trust platform, one that only reveals itself when connectivity is lost.

Every cloud-managed Zero Trust platform is built on an assumption that never appears in the product datasheet: enforcement points require continuous connectivity to the central controller to function. In denied, disrupted, intermittent, or limited-bandwidth environments: a forward operating base under jamming, a naval vessel on constrained satellite bandwidth, an air-gapped OT facility managing critical infrastructure: that assumption fails. The system either fails closed, denying all access when the controller is unreachable, or fails open, defaulting to permissive access. Neither is acceptable.

Volt Typhoon targeted exactly these environments. CISA confirmed that PRC-sponsored actors achieved five-plus-year persistent access to U.S. critical infrastructure by choosing the IT/OT management corridor, specifically environments where intermittent connectivity and legacy architecture made the management plane underdefended.

The architectural fix is not complicated to state, though it was hard to build: separate governance from enforcement. Let administrators define policy centrally. Let enforcement happen locally at every node without requiring a controller. Synchronize when communications allow. Enforce locally when they do not. This is what a distributed control plane does, and precisely what the enterprise security industry abandoned in its race toward centralization.

What distributed control plane architecture actually means

Invisinet was built on this principle from day one, originally for the Department of Defense to protect warfighters in contested tactical environments, now deployed across enterprise, OT/ICS, maritime, and cloud environments where mission continuity cannot be conditioned on cloud connectivity.

Every InvisiGate gateway is a fully capable, independent enforcement point. There is no crown-jewel controller for an adversary to target. Policy updates are published once and distributed asynchronously to subscribing nodes via a publish-subscribe synchronization model. Each node validates and applies changes independently. If communications are interrupted, nodes enforce their last-known-good policy without degradation. Not a fallback mode: the designed operational state. When connectivity returns, they reconcile automatically.

An adversary who compromises the management plane does not thereby compromise enforcement on any other node. That property is what every centralized architecture lacks by design and cannot acquire through patching.

 

No Single Point of Operational Failure

First Packet Authentication: Why Enforcement Timing Is Everything

Most security architectures share a design constraint that rarely gets named directly: the protected resource must be at least partially reachable before any authorization decision is made. A firewall evaluates a packet after the network layer processes it. A VPN authenticates after a tunnel is built. A ZTNA broker validates identity after a TLS handshake completes. In every case, the enforcement layer is visible, responsive, and therefore a reconnaissance target.

Even a firewall deny is information. It confirms the resource exists, what port it runs on, and something about how it responds.

Volt Typhoon’s documented methodology starts there: FOFA-based scanning to identify reachable enforcement points, map the perimeter, and build the attack from what it reveals.

Invisinet inverts this. A TAC-ID, a cryptographic one-time-use identity token, is embedded in the TCP SYN packet, the very first packet of every session attempt, before any session exists. InvisiGate validates the TAC-ID before a session is established. If the token is valid, the session proceeds and the protected resource remains hidden from the requesting party. If the token is absent or invalid, the packet is silently discarded. No TCP RST. No ICMP unreachable. No banner. No acknowledgment that anything exists.

A firewall deny confirms existence. A silent discard confirms nothing. Volt Typhoon’s reconnaissance tools return empty results. The attack surface that every intrusion campaign depends on finding simply does not exist.

The credential problem that policy cannot solve

Most credential-based attacks share one assumption: that possession of a valid credential is sufficient to gain access. Pass-the-hash and pass-the-ticket techniques exploit exactly that assumption. They work because the architecture treats credentials as the key.

Volt Typhoon’s documented IT-to-OT pivot relied on exactly this: harvest credentials from IT systems, use those credentials to access the management corridor connecting IT to OT, pivot through the jump host into the OT environment. The credentials are the key because credential-based authentication treats them as the key.

 

Quantum Resilience: Architectural, Not Algorithmic

The quantum threat to cryptographic credentials centers on the harvest-now-decrypt-later strategy: capture encrypted session tokens or credentials today, decrypt them when quantum computing becomes sufficiently powerful. Nation-state actors with long planning horizons are already executing this strategy. The data they are collecting now will be decrypted later.

This strategy fails against TAC-IDs for a fundamental reason: there is nothing to harvest. One-time tokens used once and discarded leave no persistent cryptographic material to accumulate. By the time a captured token could theoretically be decrypted, it has already been invalidated.

Replay resistance is built into the architecture. It does not depend on computational hardness assumptions that Shor's algorithm could eventually challenge. TAC's first-packet token mechanism does not rely on asymmetric cryptography. No RSA. No ECC. Shor's algorithm does not apply to the authentication path. Invisinet is architecturally quantum-resilient today, not as a future roadmap item.

Where TIC 3.0 Points and Where It Stops

CISA’s June 2026 TIC 3.0 guidance correctly identifies the TIC 2.0 problem: routing all agency traffic through centralized MTIPS access points created performance bottlenecks and limited cloud adoption. The SASE architecture it prescribes moves enforcement closer to the workload and is a real improvement. I want to be clear about that.

But SASE distributes where traffic is inspected while centralizing what governs the inspection. Every PoP and endpoint agent depends on the SASE management plane for policy decisions. Disconnect them and enforcement degrades or fails. TIC 3.0 replaced a centralized on-premises chokepoint with a centralized cloud SaaS control plane. The traffic architecture improved. The single-point-of-failure property did not.

For OT environments, the gap is sharper. TIC 3.0’s guidance wraps the IT management path to OT in a ZTNA session but does not protect OT/ICS protocols at the network layer. That is precisely where Volt Typhoon operated. The jump host and the ZTNA identity stack that gates it become the attack surface. Protecting OT at the network layer requires enforcement at the first packet, before any session exists.

 

Operational management at distributed scale

The strongest historical objection to distributed security architectures has always been operational: distributed means complex, and complexity means cost. Every autonomous enforcement node requires policy updates, software lifecycle management, cryptographic material, configuration consistency, and state synchronization. Without automation, that burden grows prohibitive as deployments scale.

That objection was valid when it was first raised. It is no longer valid.

Sigma Cloud, Invisinet’s fourth-generation Infrastructure as Code platform, was built specifically for distributed, occasionally disconnected environments. Build servers are instantiated for a deployment task and destroyed afterward: no persistent management server, no standing attack surface equivalent to what made SolarWinds Orion effective. Each site runs a local reconciliation engine that converges infrastructure to the desired state with no cloud connectivity required. When connectivity returns, delta changes synchronize in both directions. Certificates are provisioned, rotated, and revoked automatically; certificate expiry does not create enforcement failures during disconnected operation because locally cached certificates remain valid against the local trust store.

The result is central policy authoring with distributed policy execution: the governance model enterprise security organizations require, and the resilience model mission-critical environments demand. Same platform.

The architecture that matches the adversary

The centralization bet made sense when adversaries were opportunistic, and connectivity was reliable. Neither assumption holds today.

State-sponsored actors have a documented and consistent strategy that exploits concentrated management authority. The operating environments where security matters most cannot depend on reliable cloud connectivity. Credential-based authentication is systematically exploited by the actors who present the highest risk.

A distributed control plane architecture is the correct response to all three of these realities. It removes the high-value target that centralized controllers create. It makes enforcement independent of connectivity. It replaces reusable credentials with one-time ephemeral tokens that cannot be replayed regardless of what an adversary captures.

Brendan Sullivan is the CEO of Invisinet Technologies.  To learn more about how Invisinet's First Packet Authentication™ and Software Defined Perimeter platform can protect critical infrastructure, visit invisinet.com or request a demo.

Table of contents
sign up for newsletter
Receive updates on Invisinet’s solutions and security insights.