Sixty-four percent. That's the rise in ransomware attacks against industrial organizations in a single year, and manufacturing has now been the most-attacked sector for five years running. Layer in a detail security teams don't like to say out loud: dwell times of five years have already been documented inside U.S. critical infrastructure. Not five days. Five years.
Every enterprise security leader I talk to has some version of a cloud-brokered SASE platform protecting their users and applications. And nearly all of them are asking the same question this year: why does AI keep finding a way around it?
The honest answer isn't that these platforms are poorly built. They were built to solve a different problem than the one AI just created, and the architecture they all share has a boundary that AI-driven connectivity runs straight into.
The Anchor Is Sound. That's Not the Argument.
I want to be precise here, because this isn't a knock on the category. Enterprise cloud SASE brokers earned their position honestly. A client and an app connector each dial outbound to the broker's cloud exchange, which stitches those micro-tunnels into a single mutually authenticated path. The application keeps no inbound port and no public address. For a distributed workforce reaching SaaS and private applications, that model is close to ideal, and it is the shared design underneath every major cloud-delivered SASE platform on the market today.
That design is genuinely strong across three specific domains: user identity, device posture, and application access. Measured against the DoD Zero Trust Reference Architecture 2.0, a well-deployed cloud broker routinely scores in the 85 to 95 percent range across those three pillars. Nothing in this piece argues for ripping that out. You should not.
The architecture has a dependency, though, and it's the same dependency regardless of which vendor's logo is on the console. A cloud broker must be reachable to enforce policy, an agent must run on the endpoint for the broker to see it, and something on the other end must answer a probe for the broker to establish a session. Those three assumptions held for a decade of "user reaching app." They do not hold for the environments AI is now forcing every enterprise to connect.
AI Dissolved the Air Gap
Every serious AI initiative in an asset-intensive enterprise requires two things the air gap was specifically designed to prevent.
Data must leave the plant. Predictive maintenance, quality vision, and yield optimization all stream historian and sensor data to IT and cloud analytics platforms that were never part of the original OT design. And decisions have to come back. Closed-loop optimization writes setpoints directly into control systems, which means the read-only boundary that made one-way data diodes acceptable for twenty years quietly becomes bidirectional.
At the same time, legacy equipment is getting connected on a timeline the security team didn't set. Hardware specified in 2005 for an isolated network is now bridged so a model can reach it, with no authentication of its own and no capacity to run an agent, cloud-based or otherwise. And the perimeter itself has moved. An attacker no longer needs the PLC. Poisoning training data or optimization logic can influence physical outcomes without ever touching a controller directly.
The result, across every industrial and critical-infrastructure enterprise I've sat across the table from this year, is the same. A control network that is now routable from the enterprise, populated with assets that cannot authenticate or defend themselves, expanding on a schedule the AI program sets rather than the one security would choose.
The Model Has Been Tested. It's Been Breached.
Volt Typhoon established persistence inside U.S. critical infrastructure by exploiting internet-facing edge appliances, then living off the land: valid credentials, native tooling, traffic indistinguishable from an administrator's. Salt Typhoon reached at least nine major U.S. telecommunications carriers, including the lawful-intercept systems they operate. Neither campaign defeated encryption. Both needed only a reachable path and a session that looked trusted.
The regulatory response has moved fast, and it has moved specifically toward operational technology. Between December 2025 and July 2026, federal guidance progressed from principles for integrating AI into OT, through a national cyber strategy naming the grid, water utilities, telecommunications, and hospitals as defended terrain, to CISA guidance on adapting Zero Trust to OT, and finally to CI Fortify, which instructs operators to plan for running isolated and compromised for weeks to months without outside help. Guidance like this becomes sector regulation. Regulation becomes insurance and contract language. The enterprises moving now are ahead of both the audit and the underwriter.
Where the Whole Category Runs Out of Runway
Here's the part that applies regardless of which broker sits on your architecture diagram. The 2026 OT guidance keeps the Zero Trust policy model intact; it just changes what implementation has to mean, and every cloud-brokered SASE platform inherits the same five gaps because they share the same design premise.
Enforcement location shifts from a centralized policy engine consulted per request to a segmentation point that has to sit beside the operational asset itself. Control-plane dependency shifts from assuming continuous connectivity to requiring enforcement that survives degraded, intermittent, and fully disconnected operation. Identity scope has to expand from user-to-application, brokered by a cloud proxy, to machine and workload identity on PLCs, RTUs, and HMIs that were never built to run an agent. Discovery has to go from active scanning and endpoint telemetry to passive only, because a scan that fingerprints an IT host can halt a production line. And third-party access has to move from broad VPN tunnels onto the control segment to per-session, least-privilege, attributed access that preserves Purdue-model isolation.
None of that is a critique of any single vendor's engineering. It's a description of a category boundary. A proxy has to answer to operate. Its certificates, errors, and banners fingerprint the stack behind it to anyone probing it, adversary included. A cloud broker has to be reachable to enforce, which is exactly the assumption that doesn't survive contact with a disconnected substation, a 20-year-old SCADA protocol, or a direct-to-device satellite link. That's true regardless of which cloud-brokered platform is running the rest of your architecture.
What Closes the Gap
Invisinet didn't start as a SASE competitor. It came out of a Department of Defense requirement set for cloaking IP-connected devices on contested networks: no assured connectivity, no agent on the endpoint, no tolerance for a control that generates its own traffic. That's the same requirement set the 2026 OT guidance now describes for the rest of the economy, and it's why the product closes the gap rather than competing for the same territory.
First Packet Authentication™ validates a one-time-use identity token carried in the TCP SYN, before any handshake occurs. Traffic without a valid token is silently discarded in both directions. There's no certificate to fingerprint and no banner to enumerate, because Invisinet never answers. An east-west scan launched from an already-compromised host returns nothing. That matters enormously against living-off-the-land tradecraft, where the hardest problem is that an attacker holding valid credentials looks exactly like your own administrator. A stolen password doesn't generate a valid token, so credential theft stops producing network access.
Identity travels at Layer 4 rather than Layer 7, carried in the packet header itself, and it can represent a person, a process, or a thing. Deployment is agent-based where an agent can run and agentless through an IoT gateway where it can't. That is how a PLC that has never run a security agent in its life acquires a verifiable network identity without being touched or replaced. Enforcement is distributed: every gateway applies policy independently and reverts to local autonomy the moment the WAN, the cloud, or a vendor console goes dark, which is the actual definition of surviving degraded and disconnected operation rather than a marketing claim about it.
None of this displaces the anchor investment. It operates at a different layer, at a different point in the kill chain. Measured against the DoD Zero Trust Reference Architecture's five pillars, a strong cloud broker alone is genuinely capable on User, Device, and Application, and structurally weak on Network/Environment and Visibility & Analytics, the two pillars a cloud proxy can't reach no matter how well it's configured. Paired with Invisinet, those two pillars go from a real, measurable gap to full coverage, while the three pillars the broker already owns get stronger still. The two products compose. They don't overlap.
The same pre-session control that closes the OT gap improves enterprise IT, too. Content-aware DLP, including the DLP built into every major SASE platform, can only evaluate a session after it's already open. It can't evaluate whether the path itself was legitimate to begin with. An adversary replaying valid credentials over a permitted route produces traffic that looks authorized, because by the time DLP sees it, it is. Placing an identity check in front of that layer shrinks the number of sessions that ever reach inspection, governs every third-party and machine-to-machine connection before the socket opens, and gives the SOC a named identity per flow instead of an address to reconstruct after the fact.
Where to Start
The evaluation question is narrower than it sounds. Identify the assets in your environment that cannot run an agent, cannot tolerate an active scan, or must keep enforcing policy when the WAN goes down. In every enterprise I've worked with, that set is larger than the first estimate once industrial, building, medical, and remote-site systems get counted honestly. That's where a cloud-brokered architecture, any cloud-brokered architecture, has no reach, and it's where AI is expanding your attack surface the fastest.
A proof of concept is correspondingly small. Invisinet installs as an identity overlay on the network and protocols you already run: no re-IP, no new VLANs or ACLs, no hardware refresh, no downtime. One boundary, inside one maintenance window, is enough to see the silent-drop behavior, the per-flow attribution, and the disconnected-operation survivability for yourself.
Your SASE broker earned its budget line, and it should keep it. But AI just handed it a job it was never built to do, and no amount of configuration will make a cloud proxy reach a disconnected substation or authenticate a PLC. That job needs a purpose-built answer, not a bigger version of the same architecture. Invisinet is that answer. It is the identity layer built from the ground up to close the exact gap your SASE broker cannot close on its own. Deployment takes weeks, and the results are provable inside a single maintenance window.
Brendan Sullivan is the CEO of Invisinet Technologies. Invisinet's First Packet Authentication™ technology is patented and FIPS 140-3 validated. It is currently deployed in U.S. government and critical infrastructure environments. For more information, visit invisinet.com.
