Why event streaming in air-gapped networks needs its own design
On an isolated network, the platform choice matters less than three things: how software gets in, how the platform is watched without cloud tooling, and how quickly the stack is patched after a release. A team that must run brokers in a classified enclave, an OT zone or a sovereign government network has no internet route to fall back on, so every container image, Java runtime, broker release and connector plugin must be fetched, verified and carried across the boundary by a process the team controls. Kafka, NATS with JetStream and RabbitMQ can all be run this way. Kafka fits when Kafka Connect, its connector ecosystem and Kafka API clients are the requirement. NATS with JetStream suits a small footprint and low-latency messaging, and its server is a single binary. RabbitMQ fits AMQP-centric workloads. The details of each follow in the sections below.
The import path deserves the earliest design work because it sets the pace of everything else. Kubernetes clusters can be built offline by pre-pulling control plane images and pointing kubeadm at a private registry, and the same principle applies to broker images, Java runtimes and plugins. Ask who verifies each artifact's integrity and authenticity before it crosses the boundary, and whether that step is written into procurement and change control. NERC CIP-013-2 addresses this for energy sector vendors, and similar supply chain expectations apply in other regulated sectors. Confirm with your security team which signing and checksum process they accept, and document it before the first transfer, not after an audit asks for it.
Patch cadence is the risk most likely to be underestimated. Apache Kafka lists 4.3.1, 4.2.2 and 4.1.2 as supported releases, and rolling upgrades are supported from the last three releases to the latest version, so a platform that falls behind may need a multi-step upgrade. Since Kafka 4.0, brokers and Kafka Connect require Java 17, so Java and broker versions must be planned together. Monitoring also has to run offline. Confirm that your metrics, log and alerting stack is self-hosted and has its rule and data updates delivered through the same import path, because a monitoring stack that calls home will be blocked and silent when you need it most.
Requirements an isolated broker must meet and where they come from
This table maps the control intent behind each requirement to the evidence an assessor expects and the build decision it forces on an isolated Kafka or NATS deployment. Read each row as a question to answer in your own design: which standard applies, and what the broker, network and release process must show.
| Requirement | Source and control intent | What it means for the build |
|---|---|---|
| Remote access through a controlled intermediate point | NERC CIP-005-7 (electronic security perimeters) requires interactive remote access to high and medium impact systems to pass through an Intermediate System with encryption and multi-factor authentication, and to detect and disable active vendor sessions | Broker administration from outside the perimeter goes through a hardened jump point with MFA and session logging. Vendor support sessions need a documented way to be detected and cut off. |
| Encrypted client and broker traffic | Kafka supports SSL/TLS between clients, brokers and tools, and security is optional, so unsecured or mixed listeners are possible (Kafka security overview) | Disable plaintext listeners in the isolated zone. Confirm each client library and Kafka Connect worker is configured for TLS before go-live. |
| Client and tool authentication | Kafka supports SASL mechanisms GSSAPI (Kerberos), PLAIN, SCRAM-SHA-256, SCRAM-SHA-512 and OAUTHBEARER, alongside SSL (Kafka security overview) | Choose a mechanism your identity source can serve inside the boundary. Confirm whether an internal Kerberos realm or SCRAM credential store is available without internet reachability. |
| Default-deny authorization | In KRaft clusters the StandardAuthorizer keeps ACLs in the metadata log, and resources without ACLs are limited to super users unless allow.everyone.if.no.acl.found is true (Kafka authorization docs) | Keep the flag at its restrictive default and grant topic, group and cluster ACLs per application. Record ACL exports as evidence of least privilege. |
| Software integrity and authenticity for patches | NERC CIP-013-2 expects supply chain processes to verify vendor software integrity and authenticity, including patches (NERC CIP-013-2) | Verify checksums and signatures on every Kafka, Java, connector and NATS binary before it crosses the boundary, and keep a transfer log per package. |
| Supported versions and upgrade path | Kafka supported releases are listed on the downloads page; Kafka 4.0 is KRaft-only and requires Java 17 for brokers and Connect (Kafka upgrade notes) | Plan Java and broker patch cycles as one change. Confirm the target release is supported before building the import bundle, and rehearse rolling upgrades in a staging enclave. |
| Operational technology guidance | NIST SP 800-82 Rev. 3 gives security guidance for operational technology, including segmentation and controlled data flows between zones | If brokers bridge OT and IT zones, document the one-way or filtered flows, the owner of each zone and how monitoring works when the link is isolated. |
| Contract-driven frameworks | CMMC (32 CFR Part 170) and FedRAMP scope (M-24-15) apply only where a contract, agency or customer requires them | Confirm with the contracting authority whether either applies before designing evidence. Do not assume scope from the network being isolated. |
How releases, images and connector plugins cross the boundary
The transfer workflow starts in a staging zone that can reach public repositories, and ends in an isolated registry and artifact store that the broker hosts can reach. In staging, build a mirror of every container image, Maven artifact and package the platform needs, including the broker archives, the Kafka Connect plugins and the Java runtime. Verify each item against its published signature and checksum before it is allowed to cross, and record the result. Kubernetes gives a model for the image side: kubeadm can pull control plane images in advance with kubeadm config images pull, and its --image-repository flag points kubeadm init at a private registry, so nothing has to be fetched at install time. GitLab's offline environment guidance follows the same pattern for self-managed installs, so the approach is well documented even though the broker stack has its own artifact list.
Kafka Connect plugins, the Java runtime and the broker archive are linked by version, so they must move in one controlled batch. Apache Kafka 4.0 and later require Java 17 for brokers, Kafka Connect and tools, so a broker upgrade that lands without the matching JDK will fail at startup, and a connector built against an older Connect API may not load. Before the batch is approved, confirm the target broker version against the supported releases on the Kafka downloads page, check that each connector plugin declares compatibility with that version, and confirm the JDK build your security team has approved. Ask each connector vendor or project for its build provenance and the exact version it was tested against.
Every batch needs a recorded bill of materials that lists each artifact, its version, its source URL, its hash, the signature verification result, the approver and the date it entered the isolated side. Keep that record with the change ticket and store a copy outside the isolated network so an auditor or incident responder can reconstruct what is running. This is also the evidence that supports the supply chain controls in NERC CIP-013-2 where that standard applies. Ask your implementation partner to show how the bill of materials is generated, who may approve a batch, and how a rejected artifact is quarantined and removed from the staging mirror.
Which open-source brokers fit an air-gapped deployment
Broker choice in an isolated network is shaped by licensing, how releases and plugins reach the enclosed environment, and how much upgrade work the team can absorb. The cards below cover the options most often shortlisted, with the checks to run before committing.
Apache Kafka
Kafka is licensed under Apache-2.0 and the project itself offers no paid edition, so the software cost is the same whether the cluster is connected or isolated. The supported releases listed on the downloads page are 4.3.1, 4.2.2 and 4.1.2, and Kafka 4.0 and later run only in KRaft mode, so any ZooKeeper-era cluster must migrate first. Plan the import of broker, Connect and tooling artifacts, and confirm with the vendor or Kafka community which build, plugin and dependency repositories you must mirror. Java 17 is required for brokers and Connect.
NATS with JetStream
NATS is licensed under Apache-2.0 and sits under the Cloud Native Computing Foundation, with development continuing under that license after the 2025 trademark transfer. The server is a small single binary with a typical memory footprint of about 15 MB, which keeps the artifact set small to carry across an isolated boundary. JetStream adds at-least-once persistence. For production, the NATS documentation calls R3 replication the floor and recommends an odd number of servers. Confirm how Helm charts and client libraries will be mirrored.
RabbitMQ where AMQP decides
Choose RabbitMQ when existing applications already speak AMQP 0-9-1 and routing, acknowledgements and dead-letter handling are built around it. The broker's open-source license and its enterprise add-ons should be checked against your procurement rules before you commit. In an isolated network, the import burden includes the Erlang runtime, plugins and any container images, so confirm the exact plugin set and the upgrade path with the maintainers and your partner before the first build.
Apache Pulsar where tiered storage decides
Pulsar fits when multi-tenancy, geo-replication or tiered storage to object storage is a firm requirement. Its component count, including brokers, bookies and ZooKeeper or metadata services, multiplies the artifacts to import and the components to patch. Confirm with the community which Helm charts, tiered storage connectors and Java builds you need to mirror, and test an upgrade across the components before relying on the design in an isolated site.
Check air-gapped support in the license
Some vendors gate offline or air-gapped deployment behind paid editions. Mattermost places air-gapped deployment in its Enterprise Advanced plan, Rocket.Chat excludes it from its free Starter plan, and Metabase offers it only on its Enterprise plan. Broker projects differ, so read the license and edition terms for each product you shortlist, and ask in writing whether offline installation, updates and support are included in the edition you will run.
Verify every artifact before it crosses
Whatever broker you choose, each release, plugin and dependency crossing the boundary needs a recorded integrity and authenticity check. NERC CIP-013-2 addresses verification of software integrity and authenticity for vendor software and patches, which is a useful model even outside the energy sector. Define who signs off on imports, how checksums are recorded, and how the broker's Java runtime and operating system packages are updated on the same cadence.
Deployment patterns for one-way transfer between classification levels
Each pattern moves event data across an isolation boundary in a different way, and each fails differently. The cards below cover the integration point, the failure mode and the question to put to the accreditation authority for five common designs. Choose the pattern before sizing the cluster, because it decides who may connect to what and how data is verified on arrival.
Single isolated cluster with manual transfer cell
The broker runs entirely inside one enclave, and every release, connector plugin and container image enters through a manual transfer cell where media are scanned and hashes are recorded. The integration point is the transfer cell procedure itself, not a network link. The main failure mode is an unverified package that passes review because the checklist was incomplete, so the dependency list for each Kafka release, its Java runtime and any connector must be built before the first import. Confirm with the accreditation authority which media types and scanning steps they accept.
High-side cluster fed through one-way gateway
A one-way gateway pushes events from a lower classification level into a higher-level cluster and never permits traffic back. The integration point is the gateway's filter policy, which must define which topics, schemas and payload sizes cross. The failure mode is silent loss or corruption when the gateway drops malformed records, so producers need sequence numbers and the receiving side needs gap detection. Confirm with the accreditation authority how the gateway is evaluated and whether acknowledgments are permitted to flow backward.
NATS leaf nodes into a core cluster
A NATS leaf node at a lower level connects outbound to a core cluster and exposes only the subjects its account permits. The integration point is the leaf connection and the account mapping, which keeps messaging domains separate on the core side. The failure mode is a leaf that reconnects after a long outage and replays stale state, so JetStream stream and consumer settings must be checked before reconnection. Confirm with the accreditation authority whether a leaf link counts as a permitted connection and who approves the account permissions.
Kafka replication where policy permits
Kafka MirrorMaker-style replication copies topics between clusters on different levels only when the security policy explicitly allows the data flow. The integration point is the mirror link between two clusters, which carries both data and consumer offsets, so it must be treated as a cross-boundary connection. The failure mode is a mirror that quietly continues copying after a policy change, so the topic allowlist must be enforced at both ends and tested. Confirm with the accreditation authority whether replication counts as a transfer and what evidence of the allowlist they require.
OT zone broker bridged to IT zone
A broker in the operational technology zone collects machine and control data, and a bridge forwards selected topics to an IT zone broker for analytics. The integration point is the bridge, which should initiate connections outward from the OT side and carry only one direction of data. The failure mode is a bridge that fails open during a link fault, exposing OT topics to a wider audience, so default deny rules and a tested fail-closed behavior matter. Confirm with the accreditation authority how the OT boundary is defined and which zone owns the bridge.
Monitoring without cloud tooling and keeping Java and brokers patched
Metrics, logs and alerts have to run on components inside the isolated network. A broker you cannot reach from a cloud console still needs a local path for health, lag and disk data. NATS documents a Prometheus exporter, so a NATS deployment can feed a self-hosted Prometheus and Alertmanager that never call out. Kafka has no single vendor monitoring product, so the team should choose a JMX-based exporter, a Prometheus-compatible stack and dashboards before go-live, and confirm that every container image, chart and dashboard file has been carried across the boundary with the rest of the stack. For host and network visibility, Wazuh publishes an offline installation guide and can use an offline vulnerability repository in place of the Wazuh Cyber Threat Intelligence platform. Security Onion supports full installs without internet access and updates from newer ISO media in airgap mode through soup. Confirm which of these fit your classification and staffing model, and test alert delivery to a local destination before you rely on it.
Every patch is a transferred, verified artifact, so plan patching as a repeatable import process. Kafka's time-based release plan supports rolling upgrades from each release in the past year, which is the last three releases, to the latest version, so a cluster that falls behind may need intermediate steps. Two rules shape the path. ZooKeeper-based clusters must migrate to KRaft before upgrading to 4.x, because 4.0 supports only KRaft mode. The upgrade notes also recommend that KRaft clusters older than 3.3.x move to 3.9.x before moving to 4.x. Java is a separate dependency: since Kafka 4.0, brokers and Kafka Connect require Java 17, and clients and Kafka Streams applications require at least Java 11. Patch the JDK, the broker and the connector plugins in a staging enclave first, verify checksums and signatures against the vendor's published values, and record each step as evidence for your change and supply chain controls. Ask your partner to show how a patch cycle moves from the import point to the production broker.
How the approach changes by network type
In a fully disconnected enclave, nothing crosses the boundary over a network path. Broker binaries, Java runtimes, connector plugins, container images and vulnerability data all arrive on approved media, are verified, and are then imported into a local registry and package store. Monitoring has to run on the enclave's own tooling because no cloud service is reachable, so the local metrics, logs and alerting stack is the source of truth for cluster health.
- Transfer cadence: Agree a fixed import cycle with the accreditation authority and treat each cycle as a controlled change. Kafka publishes three releases a year on its time-based plan, so the cycle must be able to absorb a new release without a special exception.
- Patch windows: A security fix only takes effect after it has been staged, hashed and imported, so the window is set by the transfer cycle rather than by the vendor's release date.
- Software bill of materials: Carry a manifest with every import so each broker, Connect plugin and Java runtime version can be traced to its source artifact.
- Local monitoring: Build dashboards and alert rules inside the enclave and test them with a deliberate broker failure, because there is no external watcher.
- Kubernetes bootstrap: If the cluster runs on Kubernetes, pre-pull control plane images with kubeadm and point the install at the private registry.
Confirm with the accreditation authority which media, hashing and approval steps apply before the first import.
A semi-isolated OT zone usually has a controlled path to the IT network, often through a one-way or tightly filtered gateway, and transfers happen on a schedule rather than continuously. The broker sits inside the zone, so the zone's security monitoring is the source of truth for event flow and access, and a copy of the key signals goes to the enterprise monitoring stack after each transfer. Patch windows depend on plant maintenance schedules and the safety approvals that apply to the process.
- Transfer cadence: Match imports to the scheduled transfer windows of the gateway, and keep the release and approval record for each import so the transfer can be audited.
- Monitoring source of truth: Use the OT zone's own log collection and intrusion detection, such as an open source sensor platform, and forward only the agreed signals across the boundary.
- Upgrade paths: Kafka supports rolling upgrades from each release in the past year to the latest version, so plan multi-hop upgrades in advance rather than waiting for a plant outage that allows a large jump.
- Java and runtime pinning: Brokers and Kafka Connect require Java 17 from Kafka 4.0 onward, so verify the runtime version in the zone before scheduling a broker upgrade.
- Access control: Treat remote vendor access as a regulated path. For energy assets, NERC CIP-005-7 governs how Interactive Remote Access passes through an intermediate system.
Ask the operator to document the maintenance calendar and gateway transfer windows before the upgrade plan is set.
A sovereign cloud with no public egress keeps the platform in a cloud account that is run under local control, with outbound internet access blocked and only private endpoints allowed. Software reaches the environment through a private mirror or a provider-controlled import path, not through public package repositories. Cloud-native monitoring can often be used, but it must be confirmed that the tooling runs entirely inside the sovereign boundary and does not call external endpoints for licensing or telemetry.
- Transfer cadence: Confirm how the provider loads images and packages into the private mirror, and who approves each load.
- Monitoring source of truth: Decide whether metrics and logs stay in the sovereign account. Confirm that any managed observability service keeps data in the required jurisdiction and works without egress.
- Patch windows: Provider change calendars and the platform's own maintenance windows both apply, so agree which party schedules each Kafka, Java and operating system update.
- Container and cluster images: Confirm that managed Kubernetes control plane images and add-ons can be sourced from the private registry, and use kubeadm only where the team builds the cluster itself.
- Evidence of integrity: Keep signed or hashed records for every artifact that enters the account, since NERC CIP-013-2 shows how supply chain verification of software and patches is expected to be documented in regulated sectors.
Ask the provider in writing which egress paths are blocked, which services need private endpoints, and how an emergency security patch reaches the cluster.
Rolling out an air-gapped streaming platform in phases
This sequence takes an isolated broker cluster from accreditation scoping to a tested, patchable service, with each phase closing on a written output that the accreditation owners can review. The order matters because security controls such as TLS, SASL or mTLS and ACLs must be in place before any producer or consumer connects.
Map the boundary and agree accreditation owners
Document which networks, classification levels and enclaves the streaming platform will touch, which systems produce and consume events, and which data may cross each boundary. Name the accreditation owners, security engineers and operations leads who sign off each decision, and agree the Kafka, Pulsar or NATS choice against the requirements checklist. The output is a signed boundary diagram, a data flow inventory and a list of approved transfer paths. You know it is done when every proposed topic has an owner and a classification.
Build the mirror and transfer tooling
Define how releases, container images, Java runtimes, connector plugins and rule sets are obtained on the connected side, verified for integrity and authenticity, packaged and carried across the isolated boundary. Set up a private artifact registry and package repository inside the enclave, and agree the one-way transfer procedure with the team that operates the cross-domain device. Confirm with your vendor and your accreditation owner exactly what your transfer process needs to record. The output is a documented transfer runbook and a mirror that can be rebuilt from a known manifest.
Install the cluster with TLS and authentication first
Install the brokers from the private registry, pointing the installer at internal image sources and pre-staged images, so that no step reaches the internet. Enable TLS on every listener and configure SASL or mTLS before any producer or consumer is allowed to connect, and disable any unsecured listener. Confirm the Java version required by the broker release you chose against the upgrade notes for that version. The output is a cluster that accepts only authenticated, encrypted connections, verified by a connection test from each client type.
Configure ACLs and check for open or orphaned resources
Write ACLs per topic, consumer group and cluster operation, based on the data flow inventory from the first phase. Then test the authorization configuration: confirm that resources with no ACL are denied to ordinary principals, and that the setting allowing open access when no ACL exists is off. Check that super-user accounts are limited, named and logged. The output is an authorization test report showing each topic and group tested against an unauthorized principal, and a list of exceptions with an owner for each.
Wire offline monitoring and vulnerability feeds
Deploy metrics, log collection and alerting inside the enclave, with dashboards and alert rules that work without a cloud service. Connect vulnerability detection to an offline vulnerability repository loaded through the same transfer process, so advisories reach the enclave on a known schedule. Confirm that audit logs from brokers, authentication and ACL changes are retained where your accreditation owners require. The output is a working alert test, a documented feed update procedure and a log retention setting that matches the agreed evidence requirements.
Run a first patch cycle and a restore test
Carry one broker and Java runtime patch through the transfer process, verify its integrity, and apply it in a rolling sequence so that producers and consumers keep working. Then restore a topic set from backup into a separate test cluster and confirm that messages, offsets and ACLs come back as expected. Record the time taken and the steps that needed manual work. The output is a patch record with verification evidence, a restore report and an updated runbook. Ask your partner to show both before handover.
Evidence assessors and regulators ask for from an isolated broker
This table maps each evidence item an assessor or regulator is likely to request from an isolated event streaming platform to the component that produces it. Read it as a checklist to design logging, change control and record keeping before the first audit, not as a statement that any single item satisfies a requirement. DeployOpen prepares the evidence, while independent auditors and certification bodies draw the conclusions.
| Evidence item | Produced by | What the assessor checks | Where it usually fails |
|---|---|---|---|
| Transfer logs and approval records | Cross-boundary transfer process and ticketing system | Who moved each release or plugin, when, and who approved it | Transfers done by hand with no approval trail |
| Signed artifact manifests | Release team and checksum or signature tooling | Each Kafka, nats-server, Java and connector package matches the vendor-published digest | Manifests created after install, or no record of the source |
| Kafka ACL exports | StandardAuthorizer, read from the KRaft metadata log | Every resource has an explicit ACL and no unintended access exists | Missing ACLs fall back to super users unless the default is changed |
| TLS and SASL configuration | Broker and client configuration files, plus certificate records | Encryption between clients, brokers and tools, and approved SASL mechanisms | Unsecured or mixed listeners left enabled after testing |
| Kafka version and patch records | Kafka release notes and the Kafka downloads page | Running version is on a supported release and upgrade path is documented | Clusters left on archived releases or ZooKeeper-era versions |
| nats-server version records | NATS release notes and the nats-io/nats-server releases page | Running server version is current for the chosen release line and patches are tracked | Version drift between broker nodes and no record of upgrades |
| Java version records | JVM inventory on broker and Kafka Connect hosts | Brokers and Connect run Java 17 or later for Kafka 4.x | Java runtime updated separately from the broker |
| Offline vulnerability scan results | Scanner with an offline vulnerability repository, such as Wazuh | Scan dates, scope and findings are recorded, with remediation tracked | Scanner depends on online feeds that the enclave cannot reach |
| AI Act-style event logs | AI gateway or consuming application, with logs sent to retained storage | Automatic logs exist for high-risk AI workloads and are kept at least six months under Article 19(1) | Logs written to the broker only, with no retention rule for AI events |
What to ask an implementation partner before signing
Start with the transfer path, because it is where an air-gapped streaming platform either holds or leaks. Ask how every artifact that crosses the boundary (broker builds, Java runtimes, Connect plugins, rule sets, container images) is sourced, hashed and signed before it leaves the source network, and who holds the verification keys on the inside. A partner who cannot describe a signed artifact process with a verification step on the receiving side should not be trusted with the boundary. Ask also what the partner does with checksums, whether they run a software bill of materials for each batch, and how that record supports the supply chain expectations in NERC CIP-013-2 if your environment falls under it. Confirm the exact integrity tooling with the partner rather than accepting a general description.
Next, ask how each import batch is documented and reviewed. A good answer names a manifest per batch listing every file, its version, its hash, its origin, the approver and the date it was imported into the isolated network, along with a record of what was rejected. Ask who signs off a batch and whether that sign-off is recorded in a system the security team can audit later. Upgrades deserve the same rigor: ask how a Kafka or NATS upgrade is planned when the target release and its Java requirement must be carried across the boundary in one or more batches, and how the partner checks the version path against the upstream upgrade notes before anything moves. Ask for a sample manifest and a sample upgrade plan from a past engagement, anonymized if necessary.
Finally, press on restore and monitoring, because these are where offline designs most often go untested. Ask for the restore procedure written for offline media, and ask whether the partner has rehearsed it in a separate offline test environment that mirrors the production boundary. If the answer is that restores were only verified on the production network or that no test environment exists, treat that as a serious risk. For monitoring, ask which metrics, logs and alerts the brokers expose, how they reach a dashboard without cloud telemetry, and which components run inside the boundary (for example, a self-hosted Prometheus and alerting stack, or Wazuh with an offline vulnerability repository). Ask who watches the alerts at 2 a.m. and how the partner keeps the inside monitoring stack itself patched.
Questions buyers ask about air-gapped event streaming
What drives the cost of an air-gapped Kafka or NATS install, and what is one-time versus recurring?
Cost depends on the size of the cluster, the number of isolated enclaves, and how much of the supply chain must be rebuilt inside the boundary. One-time costs usually include architecture, building an offline artifact store and private registry, hardening, initial migration of connectors and plugins, and documentation for accreditation. Recurring costs include operating brokers, transferring and verifying each release and plugin, monitoring, backups, and periodic upgrades. Ask any partner for a quote that separates these two groups, lists who is paid for each activity, and states how many transfer cycles per year the scope assumes. No fee or duration is given here because none has been supplied for this topic.
How long does an air-gapped streaming rollout take?
The pace is set by the accreditation process, the availability of approved transfer media and approvers, the number of enclaves, and how quickly the internal team can review each imported artifact. Clear requirements and early agreement on the transfer process usually shorten the work more than any technical step. Ask a partner for a written timeline that names the milestones that depend on your organization, such as security review, change approval and first controlled transfer, rather than a single overall duration. Any timeline should be confirmed against your own accreditation calendar before work starts.
What does our internal team need to provide for an isolated broker deployment?
Plan for three groups of people from your side before the engagement starts:
- Accreditation contacts who can explain the authorization boundary and sign off on controls and evidence
- Transfer approvers who review each release, connector plugin and rule set before it crosses the boundary
- Operators who will run brokers, monitor clusters, rotate credentials and apply patches after handover
Confirm named owners for each role, their availability during the rollout, and who can approve emergency transfers. Gaps in these roles are a more common source of delay than the software itself.
Can our own team run an air-gapped Kafka cluster after handover?
Yes, if the operators understand Kafka's security model and the offline process. Kafka authenticates clients with SSL or SASL, encrypts traffic with TLS when security is configured, and stores ACLs in the KRaft metadata log, with resources lacking ACLs limited to super users by default. Operators also need to handle KRaft operations, Java runtime versions and certificate rotation without internet access. Ask a partner to walk through a handover runbook, run a recovery exercise with your staff, and document which tasks remain with a retainer if your team lacks capacity for them.
Do air-gapped deployments require a paid edition or license?
It depends on the product. Apache Kafka is licensed under Apache-2.0 and has no paid edition from the project itself, so the broker needs no commercial license for isolated use. Some vendors restrict air-gapped deployment to paid tiers, so confirm the licensing of every component you plan to carry across the boundary, including monitoring, schema tooling and management consoles. Check the license text and the vendor's current plan documentation, and record the result in the architecture decision record.
How often do patches and Java updates have to cross the isolation boundary?
The frequency depends on the supported release line, the vulnerability process you adopt and how often your accreditation requires a patch decision. The Kafka project releases about three times a year and issues bugfix releases for supported versions, and rolling upgrades are supported from releases within the past year. Each cycle means importing the broker, Java runtime, connector plugins and any monitoring components, verifying their integrity and authenticity, and approving them. Ask a partner to define a patch calendar, the verification steps for each artifact, and the rollback plan if a transfer is rejected.
Which compliance controls does an isolated streaming platform need evidence for?
Supply chain verification, access control and network segmentation usually carry the most weight. NERC CIP-013-2 addresses verifying the integrity and authenticity of vendor software and patches, which is the control behind checking every package carried across an isolated boundary. NERC CIP-005-7 covers electronic security perimeters and remote access. Confirm with your assessor which framework applies to your environment, then ask the partner which evidence it prepares, such as transfer logs, hash records and configuration baselines. DeployOpen prepares systems, controls and evidence for assessments, but independent auditors issue any audit report or certification.
How DeployOpen scopes and supports air-gapped streaming
DeployOpen plans, implements, hardens, documents and supports self-hosted open-source streaming platforms inside the client's own isolated networks. For air-gapped event streaming, we start from a written scope that names the broker, the transfer path, the monitoring stack and the patch process before any work begins.
How we scope
- Agree in writing which brokers, clients, connectors and sites the engagement covers
- Map every artifact that must cross the isolated boundary, including Java runtimes, broker releases and connector plugins
- Confirm the approval path, transfer medium and checksum or signature checks that your security team requires
- Define the monitoring, log retention and vulnerability-tracking evidence your assessors expect to see
How we build
- Stand up the cluster from offline image and package bundles prepared in an approved staging zone
- Configure TLS, SASL authentication and ACLs on every listener, with unsecured listeners documented and removed
- Build a repeatable import procedure for releases and connector plugins, with hash verification recorded at each step
- Test failure modes, including loss of a broker node and a broken transfer, against the agreed scope
How we hand over
- Deliver runbooks for installing, upgrading and rolling back brokers without internet access
- Document the one-way transfer procedure, roles, approvals and evidence records for each import
- Provide configuration baselines and a register of versions, including the Java runtime and broker releases in use
- Train operators on the offline patch cycle and on the monitoring tools that run inside the enclave
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover
- Retainers can cover quarterly bundle preparation for new broker, Java and connector releases
- Support can include periodic review of ACLs, retention settings and transfer logs against your policy
- Engagements are fixed-scope, so changes to the boundary or the platform are agreed in writing before work starts
