Zero Trust Theater and Why Most Streaming Platforms Are Pretenders

“Zero Trust” used to mean something.

It described a foundational security model where nothing inside the network perimeter was implicitly trusted. Every request regardless of origin had to be authenticated, authorised, and verified. It was an operational architecture that demanded deep, pervasive control over the entire data plane.

Now the term has been weaponised by marketing. It is a logo on a sales slide, a checkbox on a compliance form, a vague corporate promise that someone, somewhere, completed a security review before the product shipped. The architecture of perpetual verification has been hollowed out into branding. And your vendor knows it.

The exact same inflation has happened to “streaming platform.”

Everyone in the modern data ecosystem is eager to claim the title. Virtually every vendor now has a product with the word “stream” in its name. But claiming it and building it are two fundamentally different things. What the market is full of is a particular species of software the “streaming pretender” that can talk about streaming, market streaming, and occasionally demo streaming, but falls apart the moment you ask it to do real, production-grade work at planetary scale. Or, worse, it technically performs the single function advertised a quick-start tutorial or a simple pipeline but in a way that becomes economically or operationally useless once you leave the controlled, benign environment of a conference keynote or a sandbox account.

These platforms either cannot sell what they are genuinely capable of doing, or they cannot actually do what they sell. And sometimes, in a remarkable display of product-market dissonance, they fail to achieve both at once.

This matters more now than it did five years ago because the regulatory environment has completely shifted. Regulation is no longer a theoretical risk that can be deferred to a later product roadmap. GDPR is old news. The Digital Operational Resilience Act (DORA) is now in force. NIS2 imposes operational resilience requirements across critical infrastructure. As we laid out in Data Sovereignty Is Existential Most Platforms Treat It Like a Feature, the industry has weaponised “sovereignty” as marketing language. Your vendor calls it compliance. Regulators call it theater.

If a platform cannot be deployed and operated precisely where a customer’s data is legally required to live and prove that control to an external auditor under pressure then the polish on its marketing page is irrelevant. Such a platform is not an infrastructure asset; it is a legal and operational liability. It is theatre, not engineering.

A real streaming platform one that can survive the audits, the scale, and the three A.M. outage calls must possess three non-negotiable properties. We must establish these boundaries before the word “platform” loses all remaining meaning in the data space.

1. Continuous Compute with Real State

The platform must do continuous compute with real state. This is the fundamental distinction between a true stream processor and a fast batch engine. A real platform operates on event time the time the event actually occurred not processing time the time the system happens to pick it up. The idea that “every few minutes is fine for most use cases” is a concession to an underlying architecture that cannot handle continuous data flow.

A real platform must handle backpressure gracefully, preventing catastrophic cascade failures. It must provide exactly-once semantics where they actually matter: not in a lab environment, but in production, during a partial system failure, at three in the morning when a downstream system is experiencing a brownout. It must manage long-lived state that survives total failure and orchestrated restarts without the operator having to rebuild the universe or lose the computation’s progress. Anything that requires a cron job, a manual restart, or risks double-counting data is a batch engine pretending to be a stream processor.

2. Usable Data Storage

The platform must store processed data in a way that remains immediately and reliably usable. If the vendor’s primary answer to the storage question is a variant of “we dump it into cheap object storage and figure out how to access it later,” they have not solved the problem of durable, accessible state. They are deferring it.

This deferral guarantees manual reprocessing, data duplication across systems, and data drift between the processing and storage layers. If an engineer must build another ETL pipeline just to make the first pipeline’s output readable by a BI tool, then the storage layer is not infrastructure. It is delayed pain, with the added insult of a high cloud bill. Effective streaming infrastructure must unify storage and processing to ensure low-latency access and prevent unmanageable, siloed data copies.

3. Control That Survives an Audit

The platform must give the customer control that survives an audit. This is the heart of the sovereignty discussion. The questions are straightforward, but the answers from most vendors are evasive: Where exactly does the data plane run? Who controls the runtime environment? Who holds the encryption keys? Who patches, upgrades, and isolates the system without calling a vendor’s support line?

If proving sovereignty requires a call to your vendor’s support team, you don’t have sovereignty. You have a dependency. For any regulated enterprise particularly in finance or government the ability to demonstrate institutional control over data and execution environment is non-negotiable. Anything below these three properties is merely theatre.

We can observe how this theatre plays out across the market.

Confluent Cloud’s Flink Offering is a prime example: a query engine in streaming clothes. On paper, they license Apache Flink. In practice, the entire experience is built around submitting constrained SQL statements to a managed service. Developers are not deploying Flink jobs as independently versioned, traceable artifacts. They are asking a proprietary service to run a pre-defined set of queries on their behalf.

There is zero support for shipping custom JAR files containing application-specific logic. That limitation alone should end the discussion for anyone who has operated Apache Flink in anger. If an organisation cannot package its own logic, version it, test it in CI, and deploy it with a full CI/CD pipeline, it does not have a general-purpose stream processor. It has a stream-enabled query engine with an aggressive marketing page.

The system talks only to Kafka topics hosted inside Confluent Cloud. Not a customer’s self-managed Kafka. Not a cluster in a different region. Everything must live within the Confluent perimeter the customer’s data flexibility ends precisely where their vendor’s billing begins. That’s lock-in with a compliance label.

Databricks has a different but equally significant problem. Databricks is genuinely excellent at large-scale batch and analytical processing. But their core offering, Spark Structured Streaming, is explicitly micro-batching. When a system processes data every thirty seconds, or every minute, that is not streaming. That is fast batch. Calling it streaming does not change the execution model any more than calling a bus a taxi changes its route.

More critically for the sovereignty conversation: Databricks is an exclusively managed cloud service. Customers cannot take the platform and run it on-premise. They cannot drop it into a sovereign private cloud. If a company’s regulatory reality dictates that the data plane must be under explicit institutional control, then “we are very secure in the cloud” is a category mismatch, not an answer. That’s compliance theatre.

A third market phenomenon is the diskless Kafka wave. Systems like WarpStream push all data directly to object storage. The pitch is compelling: stateless compute, cheap scaling, nice economics on paper. The central tradeoff is latency even the vendors are upfront that this class of system is designed for relaxed-latency workloads where a delay of a few seconds does not matter.

But this architecture exposes a deep flaw in how the industry thinks about data. It optimises for cheaper storage without asking: what happens to the data once it lands there? If data is streamed into object storage but is not immediately queryable in place, the platform has not solved a problem; it has created future work. The system has turned its storage layer into an operational to-do list for downstream teams.

This gap is why every major vendor is racing to bolt transactional tables onto streams. Confluent’s Tableflow is the canonical example: take Kafka topics, convert to Parquet, publish as Iceberg tables. Useful, absolutely. But the user still maintains two systems, an asynchronous conversion step, and lag between the “real” state in the stream and the “queryable” state in the table. They have not eliminated complexity; they have rearranged it. Who does this redundant architecture truly serve? Certainly not the developers building critical business functionality on top of it.

The big mistake most streaming platforms make and one that many buyers unwittingly reward is the obsession with speed. Speed is sexy. Speed sells. Speed benchmarks well.

But speed is rarely the actual problem.

The real problem is efficiency. Can the work be done without duplicating data across three systems and five pipelines? Once efficiency is addressed, the real problem becomes access. Can a user get to their data where it lands, in the format they need, without building yet another pipeline?

If a platform cannot provide immediate, efficient access to data where it lands, everything downstream becomes a chain of duplication: duplicate pipelines, duplicate state stores, duplicate logic, duplicate bugs. That is not technological progress. That is architectural debt with a well-funded marketing budget.

This is the problem the Streamhouse concept was built to solve.

The goal is not to force a message broker to pretend to be a database, or coerce a data lake to pretend to be a real-time stream processor. The idea is to stop forcing enterprise users to construct and maintain two separate architectures one for streaming, one for analytics and spend their careers maintaining the fragile, expensive seam between them.

Apache Flink provides the real stream processing engine: stateful, continuous, programmable, with exactly-once guarantees that hold under pressure. Apache Paimon provides the storage layer, built from the ground up for streaming semantics within a familiar, open lakehouse architecture. The customer writes data once, processes it continuously, and queries it immediately without the expense, complexity, and lag of rebuilding or copying it.

But the part that matters most the part that transforms this from technology into a real platform is the operational reality: you run it where you need to run it.

Ververica’s roots are in running Flink as mission-critical software. Our teams created Flink. We have spent the better part of a decade learning how it fails, how it scales, and what it takes to operationalise it for institutions where “it mostly works” is not an acceptable SLA. In the Ververica Unified Streaming Data Platform, jobs are treated as code packaged, versioned, and deployed as traceable artifacts with full CI/CD pipelines and rollback semantics. Not pasted into a proprietary SQL editor and hoped for the best.

Deployment is not an afterthought. The platform supports self-managed on-premise deployments, private cloud installations, and full Bring-Your-Own-Cloud (BYOC) deployments built on true Zero Trust principles where the customer’s data stays entirely within their environment. Ververica never sees or touches it. For a detailed look at how these deployment models work in practice, including real-world FSI case studies, see How Ververica Delivers Sovereignty for Financial Services.

VERA, our cloud-native engine, provides faster recovery and the ability to scale stateful applications without operational fragility all within your sovereignty perimeter. Built-in data lineage not just table-level, but field-level column lineage that traces how individual data attributes flow through transformations and audit-grade traceability are not “nice enterprise features.” They exist because without them, a customer simply cannot answer the questions European regulators are already asking.

This is not theoretical. A Tier 1 European bank running Ververica processes over 5 billion events daily with full jurisdictional lineage, and cut compliance audit preparation from six weeks to under five days. That is what sovereignty looks like when it is engineering, not marketing.

If you want to cut through the noise, ask boring, fundamental questions. Where does the data plane run? Who controls the runtime? Can I deploy real logic packaged, versioned, tested not just SQL? Can I access my data without copying it into a second system? Can I explain this architecture to a legal auditor without hand-waving?

If the answers are vague, conditional, or unavailable, the platform is not real.

Confluent Cloud, Amazon MSK, Azure Event Hubs they all make the same sovereignty-breaking choice: centralised control planes you can’t audit, in jurisdictions you can’t control. That’s lock-in with a compliance label.

Streaming is not a SQL endpoint. It is not a dashboard. It is not a vendor’s promise that “most users do not need that level of control.” It is fundamental infrastructure. And infrastructure either holds up under scale, regulatory pressure, and failure or it does not.

Most of what is sold as streaming today does not.

That is the difference between a platform and a performance.

Audit your sovereignty posture now. Download the FSI Data Sovereignty Readiness Checklist to evaluate your streaming platform against DORA, NIS2, and national residency requirements

Audit Your Sovereignty Posture Now

• Quick assessment: Download the FSI Data Sovereignty Readiness Checklist to evaluate your streaming platform against DORA, NIS2, and national residency requirements

• Structured evaluation: Apply the Sovereignty Evaluation Framework, a 26-requirement scored assessment across five sovereignty domains

• Full decision guide: Read the FSI Streaming Sovereignty Pillar Page for a comprehensive framework covering governance, deployment, Zero Trust, and sovereign AI for financial services