Self-hosted BizTalk alternative for air-gapped networks

Why a self-hosted BizTalk alternative for air-gapped networks is a different decision

If your integration server cannot reach the internet, the question is no longer which platform is cheaper or easier to run. It is which platform can keep working with zero outbound connections. Apache Camel, running with a self-operated message broker, can run fully offline because its runtime, connectors and routes sit inside your own boundary. Microsoft's successor path, Logic Apps hybrid, is only partially connected and depends on outbound access to Azure, so it does not fit a network with no internet path. Confirm that requirement with Microsoft's current documentation before you rule the option in or out, because the hybrid model changes over time.

The regulatory frames matter because they shape what you must prove, not only what you can run. In the United States, the NERC CIP Reliability Standards apply to bulk electric system operators once FERC approves them, and several of them constrain remote access, supply chain verification and electronic security perimeters that an integration server may cross. In the European Union, NIS2 lists energy, drinking water and waste water among high-criticality sectors, which brings supply chain and incident obligations into scope for many operators. Neither framework certifies a product. Whether your integration layer is in scope depends on your impact classification, your registration and your own asset inventory, so ask your compliance lead and auditors to map it before design starts.

Offline operation also changes the evidence you need. Every package, container image and rule set carried across the boundary must be verified and recorded, and every update path must be planned as a controlled transfer rather than a live pull. Decide early who owns the import process, how software integrity is checked, and how Camel and broker versions are tracked against their support windows. The Apache Camel download page lists long-term support release dates, which should drive your upgrade calendar.

What the air-gapped constraint requires from the integration layer

For utilities and other regulated operators, the integration layer sits inside a compliance boundary, not just a network diagram. The cards below set out the controls that shape where Camel and the broker can run, how remote access reaches them, what crosses the boundary, and whether NIS2 applies alongside NERC CIP.

Electronic security perimeter placement

CIP-005-7 requires routable-connected assets of high and medium impact BES Cyber Systems to sit inside an Electronic Security Perimeter. If Camel routes or the broker can reach control system assets, they fall within that perimeter. Confirm with your CIP-002 impact categorization which systems are in scope before deciding whether the integration servers sit inside, outside or on the boundary.

Interactive remote access through an intermediate system

CIP-005-7 requires all Interactive Remote Access to high and medium impact BES Cyber Systems to pass through an Intermediate System, with encryption and multi-factor authentication. Vendor support sessions into Camel hosts or broker consoles count as remote access. Plan a jump host or intermediate system, and check that it can detect and disable active vendor sessions, since the standard also requires those methods.

Verified software and patches across the boundary

CIP-013-2 requires supply chain procurement processes to address verification of software integrity and authenticity for vendor software and patches. Every Camel JAR, broker package, container image and Kaoto extension carried across the isolated boundary needs a documented check, such as signature and checksum verification against a recorded source. Your supply chain plan must also cover vendor incident notification and vulnerability disclosure, reviewed at least every 15 calendar months.

NIS2 sector scope for energy and water

NIS2 Annex I lists energy as a sector of high criticality, covering electricity, district heating and cooling, oil, gas and hydrogen, and lists drinking water and waste water as separate high-criticality sectors. An operator in these sectors in the EU may face NIS2 obligations in addition to NERC CIP, which applies in the United States. Confirm your national transposition and entity classification with your regulator or counsel before assuming scope.

Which NERC requirements apply to you

NERC CIP Reliability Standards become mandatory in the United States once FERC approves them, and NERC and the Regional Entities monitor and enforce compliance. FERC Order No. 919 states that about 1,673 unique US entities were on the NERC Compliance Registry as of June 2025. Registered Balancing Authorities, Reliability Coordinators and Transmission Operators are audited at least once every three years. Check your NERC registration and functional categories before scoping the project, since the maximum civil penalty of $1,584,648 per violation per day applies to registered entities.

Where BizTalk and its successor meet the constraint and where they do not

Microsoft's successor path, Logic Apps hybrid, keeps part of the runtime in your environment but relies on Azure for its control and management functions. Teams that want to run it inside a closed network need outbound connectivity to Azure to deploy, monitor and manage workflows, so a plant, utility or government enclave with no internet path cannot meet the constraint as the product is described without a documented exception. The Azure subscription and its billing relationship also sit outside your boundary, which affects procurement and data residency review.

Outbound Azure dependency: Logic Apps needs Azure connectivity to operate in the hybrid model, which is the central conflict with an isolated network.
Cloud-hosted connectors: Many connectors call services that live outside your boundary, so each flow depends on endpoints you may not permit.
Tenancy and billing: The Azure subscription that governs the workflows is controlled outside the network, which changes who holds administrative access.
Partial connectivity: A design that is only partially connected may run some flows offline, but each flow must be checked individually for an offline path.

Check every workflow and connector in the estate against the outbound endpoints your security team permits before you assume the hybrid path is viable.

Which open-source options fit a fully offline integration stack

This table compares the three components a fully offline BizTalk replacement needs: the integration framework, the flow-based data movement tool and the message broker. Read each row for how the option works without outbound internet access, then for the trade-offs that decide whether it fits your OT or government network. Apache Camel is the main route, with NiFi and a broker covering the rest.

Option	How it meets the offline constraint	Trade-offs
Apache Camel	Apache-2.0 licensed, so the framework and connectors can be mirrored into an internal artifact repository and built without external calls. Runs standalone, on Spring Boot or Quarkus, or on Kubernetes through Camel K.	Routes are code in Java, YAML or XML, so BizTalk developers need retraining. The 350+ connector count does not confirm coverage for your legacy OT protocols, which you must verify yourself.
Camel LTS releases	Long-term support lines receive bug and security fixes for up to one year, so patches can be staged onto offline media on your own schedule.	Each patch must be imported, tested and approved inside the enclave, so the release calendar adds recurring operational work. Confirm the current LTS dates on the Camel download page.
Apache NiFi	Apache-2.0 licensed flow-based tool for moving and transforming data between systems, deployable on your own servers with no required cloud service.	Suited to data flows and ETL-style movement more than message-level orchestration. Its visual model can be useful for operators, but it does not replace Camel routing for complex interchange logic.
Apache Kafka or RabbitMQ	Both are open-source brokers that run entirely inside the enclave and replace the BizTalk MessageBox for publish-subscribe delivery.	Broker clusters need capacity planning, backup and monitoring. Kafka suits high-volume streams, while RabbitMQ fits message routing; choose based on your ordering and retention needs.
Kaoto (optional)	Apache-2.0 visual designer for Camel routes, available as a VS Code extension, so the editor can be installed from an internal mirror.	Optional. Confirm how your team gets extensions into the offline environment, and expect that visual tooling may not cover every component you use.
Red Hat build of Apache Camel (optional)	Commercial support subscription that can be used alongside an offline deployment, covering Spring Boot and Quarkus runtimes.	Optional. It is a paid subscription, not a requirement, and it no longer supports OSGi (Karaf) or JBoss EAP, so older BizTalk-style deployments may not qualify.
Legacy OT protocol connectors	Camel connectors and community components can cover many standard protocols, but protocol coverage is not guaranteed by the connector count.	Confirm with your OT vendor and a proof-of-concept test whether each legacy protocol, serial interface or vendor gateway you need has a working component.

How to deploy Camel and a broker with no internet path

This sequence takes an isolated network from an offline Kubernetes build to running Apache Camel routes and a message broker inside an Electronic Security Perimeter, with every package and update checked before it crosses the boundary.

Build the offline Kubernetes image set
On a staging host with internet access, the platform team runs kubeadm config images list to enumerate the control plane images for the target version, then kubeadm config images pull to fetch them. Each image is saved to transfer media with a checksum recorded in the change record. The output is a complete, versioned image bundle and a manifest that the security team can compare against the list kubeadm produced. Confirm the Kubernetes version against your own support plan before pulling anything.
Initialize the cluster from a private registry
Inside the isolated network, the platform team loads the image bundle into an internal container registry and runs kubeadm init with the --image-repository flag pointing at that registry, so no step reaches a public source. Operators confirm that every control plane pod starts from the internal registry and that kubectl get nodes reports Ready. Cluster networking, node join and admission settings should be checked against the offline documentation for the chosen distribution.
Mirror Maven and container artifacts internally
Build engineers copy the Camel dependencies, the Spring Boot or Quarkus runtime libraries and the broker container images into an internal Maven repository and container registry. Each artifact is hashed, signed where the publisher provides signatures, and logged in a bill of materials. The result is a repository where a route build resolves every dependency without touching the internet. Ask the publisher or your Red Hat subscription team which signature and checksum files are available for each artifact.
Install a Camel LTS build
Developers build the routes against an internally mirrored Apache Camel LTS release. Camel 4.22.1 is LTS with end of life in August 2027, and Camel 4.18.5 is LTS with end of life in February 2027, so the choice of line sets the date for the next upgrade. Camel LTS releases receive bug and security fixes for up to one year. The check that closes this step is a successful offline build and a route smoke test that runs with the internal repository as the only source of dependencies.
Place the broker and routes inside the perimeter
The security architect confirms the zone for the Camel routes, the broker and the Kubernetes nodes sits within the Electronic Security Perimeter defined for any high or medium impact BES Cyber Systems that the traffic touches. Routable connections are limited to documented flows, and the broker's listeners are restricted to those flows. The closing evidence is a network diagram and firewall rule set that match the deployed configuration, which auditors can compare against the asset inventory.
Route remote access through an Intermediate System
Any interactive remote access by engineers or vendors goes through an Intermediate System that enforces encryption and multi-factor authentication, as CIP-005-7 requires for high and medium impact assets. The operations team sets up session detection and a procedure to disable active vendor sessions. The step is complete when a test session shows the required authentication, logging and disconnection behavior, and when the vendor access procedure is recorded under the supply chain plan in CIP-013-2.
Update only through verified media
Updates to Kubernetes images, Camel releases, broker builds and routes arrive on new media that is prepared outside the boundary. Before import, the security team verifies checksums and signatures against values from the publisher, scans the content, and records the verification in the change log, as CIP-013-2 expects for software integrity and authenticity. The import is then applied to a test enclave first. The step is complete when the test enclave runs the updated set and the verification record is filed with the change.

How the offline boundary, the broker and Camel routes fit together

The core design decision is that nothing inside the perimeter reaches outward, and everything that crosses the boundary arrives as a verified, one-way package. Camel routes, the message broker, the private container registry and the monitoring stack all run on hosts inside the isolated network, with no default route to the internet. Routes consume from and publish to the broker, which carries messages between the plant or agency systems. Camel's connectors (Kafka, JDBC, REST and so on) only reach endpoints on the internal segment, so the route definitions themselves become the first inventory of allowed flows the reader should review.

Packages cross the boundary in one direction only. On the outside, the team pulls Camel, broker, Kubernetes and monitoring images, Helm charts and rule sets, then computes checksums and signatures and records them in a manifest. Media is scanned, carried across, and imported into the internal registry, where signatures are verified again before anything is deployed. Nothing on the inside opens a connection back out, so the transfer procedure, not a firewall rule alone, enforces the one-way path. The reader should confirm with the security team which transfer device, approval chain and log retention their boundary policy requires.

Monitoring must also stay inside. Security Onion and Wazuh both document offline installs, so logs from Camel, the broker and the Kubernetes nodes can be collected and analyzed without an external feed. For Wazuh, the vulnerability detection module can use an offline vulnerability repository in place of the online threat intelligence service, which means that repository must be refreshed through the same controlled import path. Before design sign-off, confirm the control mapping for the specific standard that applies, for example the requirements in NERC CIP-005-7 for electronic security perimeters and CIP-013-2 for software integrity verification, with your auditor.

Evidence auditors and regulators ask for under this constraint

An air-gapped BizTalk replacement changes what you must prove, not only what you run. The records below connect the isolated boundary, the offline update path and the vendor remote access controls that NERC CIP-005-7 and CIP-013-2 examine. DeployOpen prepares this evidence with you, but does not issue audit reports or certifications; independent auditors and certification bodies do.

Software bill of materials and integrity records

Keep a software bill of materials for every package, container image and Camel component carried across the isolated boundary, with the version, source and checksum or signature verified for each item. CIP-013-2 expects procurement processes to address verification of software integrity and authenticity, so each transfer needs a record of who checked it and what result they found. Ask your team to confirm how signatures are validated before anything is imported.

Change records for offline updates

Every offline update, from a Camel LTS patch to a broker upgrade or an operating system package, needs a change ticket that names the artifact, the approver, the test environment and the rollback step. Track which Camel release line you run and its support end date so the change plan reflects the support window. Record each update in the same log used for configuration baselines, so auditors can trace the running state back to an approved change.

Access logs for Interactive Remote Access

CIP-005-7 requires all Interactive Remote Access to pass through an Intermediate System with encryption and multi-factor authentication, and requires methods to detect and disable active vendor sessions. Retain logs that show each session's start, end, user identity, MFA result and the Intermediate System that handled it. Confirm with your vendor and your compliance lead how long these logs must be kept and where they are stored.

Supply chain risk management plan reviews

CIP-013-2 requires a supply chain risk management plan covering vendor incident notification, vulnerability disclosure, software integrity and coordination of vendor-initiated remote access. The plan must be reviewed at least every 15 calendar months. Keep dated review minutes, the list of open vendor findings and the revisions made after each review, so the record shows the plan stayed current between cycles.

Network architecture diagrams

Provide current diagrams that show the Electronic Security Perimeter, the location of high and medium impact BES Cyber Systems, every routable connection and the single point where Interactive Remote Access enters. Mark the one-way or controlled transfer point used to carry packages across the air gap. Diagrams should match the deployed configuration, so date each revision and compare it against a live inventory before each audit.

Questions buyers ask before choosing an air-gapped integration path

What drives the cost of building an air-gapped integration platform, and who gets paid for what?

The cost comes from four components: software, infrastructure, migration labor and operations. Apache Camel and most of the broker options are Apache-2.0 or similar open-source licenses, so license fees are usually not the largest line. The larger items are the people who design routes, rebuild the offline supply chain (container images, Maven artifacts, operating system packages), stand up Kubernetes or virtual machines inside the isolated network, and run security testing. Some of this is one-time work, such as the initial build and the migration of each interface. Some recurs, such as patch intake, staff time and hardware refresh. Costs rise with the number of interfaces, the number of protocols that need custom components and the volume of data crossing the boundary. Ask any provider, DeployOpen included, for a written fixed-scope quote that separates these items and states what is one-time and what is recurring.

How long does migrating from BizTalk to an offline Camel platform take?

Duration depends mainly on the inventory of what BizTalk does today and how many interfaces must be moved in waves. The main drivers are the number of orchestrations, maps, schemas, adapters and send and receive ports, how much custom code sits inside them, and how many of those flows must keep running in parallel during cutover. Air-gapped sites add time for building the offline artifact repository, testing the isolated network path and arranging change windows with operations teams. No duration figure is supplied for this work, so ask the provider for a timeline tied to a written scope with named deliverables. Also confirm which Camel release line you will standardize on, since the release calendar affects when you must plan upgrades. Camel 4.22.1 is listed as an LTS release with end of life in August 2027, and that date should be part of your schedule.

Can our own team run an offline Camel integration platform without outside help?

Many teams can run it with internal staff, but the skill set differs from BizTalk administration. Routes are written in Java, YAML or XML, and the platform runs on Spring Boot, Quarkus, the Camel CLI or Camel K on Kubernetes, so you need people comfortable with JVM builds, container operations and Git-based change control. Air-gapped operation adds specific tasks: mirroring images and dependencies into a private registry, managing the transfer process across the boundary, and keeping an offline vulnerability and monitoring baseline. Ask whether your staff have run these steps before and which parts they would need help with. A split model, where an outside team builds and documents the platform and your team operates it, is a common option. Any such arrangement should be defined in a written, fixed-scope agreement covering handover, runbooks and training.

Does Apache Camel support the protocols and endpoints our plant or agency systems use?

Camel covers a wide range of connectors, and its repository lists more than 350, including Kafka, REST, JDBC, AWS, Azure, GCP and Salesforce. Those counts describe the project, not your environment. Before committing, list every protocol and system your BizTalk adapters use today, including older or industrial protocols, file-based exchanges and vendor-specific interfaces. For each one, confirm whether a maintained Camel component exists, whether it works offline, and whether it runs on your chosen runtime. Where no component exists, the work is custom component development, which should appear as its own line in the quote. Also confirm which Camel subproject versions you will use, because support windows differ between the core release and its LTS line.

How do we handle security patches for an air-gapped integration platform?

Patches reach an isolated network only through a controlled transfer, so the process must be designed before go-live. The usual pattern has four steps: track upstream advisories for Camel, the runtime, the operating system and the broker; download and verify each artifact outside the boundary; test the update in a staging enclave; then move the approved bundle across under change control. Camel LTS releases receive bug and security fixes for up to one year, which affects how often you must move to a new line. Verification of software integrity and authenticity is also a formal expectation in NERC CIP-013-2 for utilities. Ask any provider to document this process as a runbook, and ask who performs each step and how often it is staffed.

Is a compliance audit included in an air-gapped integration project?

No. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications. Independent auditors and certification bodies perform the assessment. For utilities, the NERC CIP standards are enforced by NERC and the Regional Entities, and there is no CIP certificate. Entities registered as a Balancing Authority, Reliability Coordinator or Transmission Operator receive an audit at least once every three years. Relevant controls include the Electronic Security Perimeter and remote access expectations in CIP-005-7 and supply chain risk management in CIP-013-2. Work with your compliance lead to map which standards apply to your asset classification, then request a written scope that lists the evidence to be prepared and the auditor, if any, who will review it.

What to confirm with vendors and your own environment before committing

Before you commit to this design, get written answers on three points: whether Microsoft's current licensing permits fully offline operation of every BizTalk component you run, whether your broker and Camel components support the OT protocols your control systems use, and which CIP standards apply to your assets. Microsoft's successor path, Logic Apps hybrid, needs outbound Azure access, so do not assume that any BizTalk runtime, license or support entitlement you hold carries over to an isolated network without confirmation from Microsoft and your licensing agreement. Ask also whether any extended support you buy requires connectivity for activation or updates.

Confirm the scope of your CIP obligations against NERC's CIP standards page rather than against a summary. The page lists 13 CIP standards as mandatory and enforceable in the United States, with separate enforcement dates for individual standards, including CIP-003-9 and CIP-012-2, and it lists CIP-015-1 and the virtualization revisions with later dates. Map each system in the integration path to its impact rating under CIP-002-5.1a, then check which standards your registration category triggers. Your regional entity or compliance counsel should confirm which dates apply to your assets.

Decide early whether you need a commercial Camel support subscription. The Apache Camel project is open source and its LTS releases receive bug and security fixes for up to a year, but production support, patch backports and vendor-issued vulnerability notices come from a commercial provider, such as the Red Hat build of Apache Camel, if you choose one. Ask any provider whether its support works with a fully offline update process, how it delivers patches across the isolated boundary, and whether it covers the Spring Boot or Quarkus runtime you plan to use. Build those answers into your CIP-013-2 supply chain plan.

How DeployOpen deploys Camel inside an air-gapped boundary

DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside the client's own infrastructure, including air-gapped networks. For an offline BizTalk replacement, the work starts with an inventory of what the network can and cannot reach, then builds an offline Camel and broker stack that is tested and handed over in writing.

How we scope

Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts
Scope lists each BizTalk orchestration, map, port and adapter to be moved into Camel routes or components
Scope records the enclave boundary, the approved transfer path for packages and the systems each route touches
Scope names the compliance evidence the team needs, such as sector-specific controls, for an independent assessor to review

How we build

Container images, Java dependencies and OS packages are gathered on an approved connected staging side, then carried across the boundary
Each artifact is checked for integrity and recorded in an inventory before it enters the offline network
Camel routes, broker configuration and monitoring are deployed to the client's own servers or Kubernetes cluster
Functional tests, failover tests and an offline install rehearsal run inside an environment matching the target network

How we hand over

Deliverables include runbooks for installing, patching and rolling back Camel and the broker without internet access
Documentation maps each migrated BizTalk artifact to its Camel route, with test results and known gaps listed
Client staff receive training on operating routes, reading logs and running the offline update process
Evidence packs are prepared for compliance assessments, although audit reports and certifications come from independent auditors

How we support

Ongoing support, upgrades and continuous testing are available as retainers after handover
Retainers can cover periodic offline update cycles, Camel LTS version upgrades and re-testing of changed routes
Security testing of the deployed integration layer can be scheduled as part of the same support arrangement
Clients should confirm response expectations, change control and vulnerability handling terms in the retainer scope before signing