Wazuh vs Elastic Security: which to choose

Wazuh or Elastic Security: which fits your SOC

Choose Wazuh when you want an endpoint and SIEM platform whose server and agent are licensed under GPL-2.0 with an OpenSSL linking exception, whose indexer and dashboard are Apache-2.0, and whose ruleset ships over 3,000 built-in rules and decoders mapped to MITRE ATT&CK. Choose Elastic Security when your organization already runs an Elastic estate and accepts Enterprise terms for endpoint malware and ransomware prevention and host isolation, or legacy Platinum terms for the detection engine and machine learning anomaly detection, since Platinum is no longer sold to new customers. Before you sign, decide which paid capabilities you need, which skills your team already has, how many endpoints and operating systems must report, and what a move would cost later.

Start with the paid features, because they decide the license line. Elastic's detection engine, machine learning anomaly detection and case management sit in Platinum, so ask Elastic in writing which current tier carries each feature on your list. Endpoint prevention and host isolation sit under Enterprise. Next, check agent coverage. Wazuh agents run on Linux, Windows, macOS, Solaris, AIX and HP-UX, so list every operating system in your estate and confirm the agents and versions each platform supports today. Finally, assess skills. Running Wazuh means operating the indexer, server and dashboard yourselves or through a partner, while Elastic's stack carries its own operating model. Your team's existing experience with these components usually outweighs feature lists in day-to-day effort.

Plan the agent layer first, because it is the costliest part to change. Wazuh documents that OSSEC agents can report to a Wazuh server, so an existing OSSEC estate can migrate in stages, as described in Wazuh's guide to migrating from OSSEC. Moving between Elastic Security and Wazuh means rebuilding detection content, dashboards and case workflows and re-onboarding agents, so ask each vendor about export options before you commit. Also note that Wazuh 4.14.9 is the current 4.x release, while a Wazuh 5.0.0 release candidate was published on October 5, 2026. Confirm your upgrade path against both. Request one quote that separates license fees, infrastructure, implementation and recurring operations, so the multi-year comparison reflects your own environment.

Which platform fits which SOC scenario

This table maps common self-hosted SOC scenarios to the platform that usually fits better, the reason, and the condition under which the other platform wins. Read each row against your own estate, and treat any cell marked for verification as an open question to confirm with the vendor before you commit.

Scenario	Better fit and reason	Other platform wins when
Greenfield self-hosted SOC with no Elastic footprint	Wazuh. Agents, indexer, dashboard, server and over 3,000 built-in rules and decoders ship under open licenses, so the core SIEM and detection content start without a paid tier.	Your team already plans on Elastic-based tooling or needs Elastic's paid detection engine and machine learning features, which sit in subscription tiers you must price.
Existing Elastic deployment	Elastic Security, because the data stores, Kibana skills and ingestion pipelines are already in place and migration cost stays low.	Your Elastic subscription terms do not cover the features you need, or you want an open-license stack and can accept a separate migration project.
Mixed Windows, Linux and macOS estate	Wazuh, since its agents cover Linux, Windows and macOS alongside Solaris, AIX and HP-UX, and the ruleset maps alerts to MITRE ATT&CK.	Your macOS or legacy endpoint coverage needs a specific agent feature set, which you must verify against current Elastic Agent support for each OS version.
Team needing endpoint malware prevention and host isolation	Elastic Security, where endpoint malware and ransomware prevention and host isolation are listed under the Enterprise subscription tier.	You want host isolation through an open-license platform and can accept that Wazuh active response is not the same product category; verify exact capabilities and any paid add-ons.
Team with an OSSEC estate	Wazuh, because OSSEC agents are compatible with the Wazuh server, so mixed OSSEC and Wazuh agents can report to one server during a phased migration.	You want to keep the original OSSEC stack unchanged, or your estate depends on OSSEC 4.x features you need to validate against Wazuh before cutover.
Air-gapped environment	Wazuh, when you can mirror its packages, rules and updates internally, because all components run in your network under open licenses. Confirm update and content delivery procedures with the vendor.	Your assessor or procurement requires Elastic's subscription support model or an offline license process; confirm how Elastic subscriptions are activated and updated without internet access.
Compliance mapping to a specific framework	Verify before choosing. Wazuh ships compliance-oriented rule groups, but mapping to your framework's control IDs must be checked against the rules you deploy.	Your auditor expects Elastic's prebuilt detection content or vendor-documented control mappings; confirm which mappings each platform supplies for your framework.
Sensitive or regulated data stored in a single search backend	Depends on the backend you accept. Wazuh uses its own indexer, a fork of OpenSearch, which you can operate in your own infrastructure.	Your team standardizes on Elasticsearch operations and staff, which may reduce operating effort compared with running a second search stack.

How Wazuh and Elastic Security are built and deployed

Wazuh ships as a bundle of four components that you install and upgrade together, while Elastic Security sits on top of a general-purpose Elastic Stack whose parts are versioned and licensed separately. The cards below compare the moving parts, the search backend each one depends on, how agents reach the platform, and what each layout means when you upgrade or run the SOC day to day.

Wazuh four-component layout

Wazuh is built from an indexer, a server, a dashboard and agents. The current 4.x line is Wazuh 4.14.9, and a 5.0.0 release candidate was published on October 5, 2026, so confirm which line your team will standardize on before you build. Plan the upgrade order across all four components, since the server, dashboard and indexer must be kept on compatible versions. Ask your vendor or partner which compatibility matrix applies to your chosen release.

Wazuh indexer as OpenSearch fork

The Wazuh indexer is an open source fork of OpenSearch, so Wazuh stores and searches alert data on an OpenSearch-derived backend that you operate yourself. This matters if your team already runs OpenSearch skills or tooling, and it means search-tier sizing, shard management and snapshot planning are your responsibility. Confirm with Wazuh how the indexer is versioned against the server and dashboard before you plan an upgrade window.

Wazuh agent coverage

Wazuh agents are available for Linux, Windows, macOS, Solaris, AIX and HP-UX. Mixed estates are common in regulated environments, so inventory which operating systems and versions carry legacy UNIX platforms before committing to a single agent rollout plan. Agents can also report from OSSEC deployments into one Wazuh server, which can ease a staged migration. Confirm agent support for each specific OS build with the vendor documentation.

Elastic Stack components for Security

Elastic Security runs on Elasticsearch for storage and search, Kibana for the user interface, and Elastic Agent with integrations for collection. The current Elasticsearch lines are 9.5.5 and 9.4.8, with 8.19.23 still maintained for teams that cannot move yet. Elastic must confirm which Security features require which subscription tier and which components, so ask for a written mapping before you assume a feature is available in your edition.

Elastic search backend and licensing

Elasticsearch is the search backend for Elastic Security, and it is distributed under three licenses: Elastic License 2.0, SSPL 1.0 and AGPLv3. The default distribution is under Elastic License 2.0, so review the license terms with counsel before you deploy, and confirm which license applies to the exact build you download. Operating Elasticsearch yourself means your team owns sizing, index lifecycle policies and cluster upgrades.

Agent deployment and upgrade effort

Wazuh agents and Elastic Agents each need a rollout plan, version pinning and an upgrade path that matches the server side. Wazuh upgrades touch four components in a coordinated sequence, while Elastic upgrades touch the cluster, Kibana and agent policies. Ask each vendor how agents are upgraded when the server moves to a new major line, and whether a rolling agent upgrade is supported in your environment.

Side-by-side capabilities from supplied facts

This table compares Wazuh and Elastic Security on license, agent coverage, ruleset, endpoint response, identity integration and release line, using only the facts we could verify. Where Elastic places a feature in a paid tier, the tier is named, and the compliance rows tell you what to confirm yourself before relying on either platform for an assessment.

Capability	Wazuh	Elastic Security
License	Server and agent under GPL-2.0 with an OpenSSL linking exception; indexer and dashboard under Apache-2.0	Source available under Elastic License 2.0 (default), SSPL 1.0 or AGPLv3; paid subscriptions for tier features
Endpoint agent coverage	Agents for Linux, Windows, macOS, Solaris, AIX and HP-UX	Confirm agent operating system coverage for your fleet in Elastic's current documentation
Built-in ruleset and ATT&CK mapping	Over 3,000 built-in rules and decoders; alerts mapped to MITRE ATT&CK	Detection engine listed under the Platinum tier, which is no longer sold to new customers; confirm current detection content with Elastic
File integrity and active response	Covered by the Wazuh agent and server; confirm configuration scope for your estate	Confirm file integrity and response capabilities and the tier that includes them in your subscription
Machine learning anomaly detection	Not applicable	Listed under the Platinum tier, which is no longer sold to new customers; confirm availability for new deployments
Endpoint malware and ransomware prevention	Not applicable	Listed under the Enterprise subscription tier
Host isolation	Not applicable	Listed under the Enterprise subscription tier
SAML or OpenID Connect single sign-on	Confirm SSO options in the Wazuh documentation for your version	Listed under the Enterprise subscription tier
Compliance framework mapping	Confirm which frameworks the ruleset maps to in Wazuh's documentation and your own assessment scope	Confirm framework mappings and content in Elastic's documentation and your own assessment scope
Current release line	Wazuh 4.14.9 (October 14, 2026); Wazuh 5.0.0 release candidate published October 5, 2026	Elastic 9.5.5 and 9.4.8 (October 6, 2026); 8.19.23 still maintained

What each license and edition covers

Wazuh splits its licensing by component. The Wazuh server and agent are licensed under GPL-2.0 with an OpenSSL linking exception, while the Wazuh indexer and dashboard are licensed under Apache-2.0. Each license carries its own obligations, so the stack is not governed by a single set of terms.

Server and agent (GPL-2.0): Distributing modified server or agent code generally requires you to make the corresponding source available under GPL-2.0 terms. Internal use within your own organization usually does not trigger distribution, but confirm how this applies to your deployment model.
OpenSSL linking exception: The exception addresses linking with OpenSSL. It does not remove the rest of the GPL-2.0 obligations for the server and agent code.
Indexer and dashboard (Apache-2.0): Apache-2.0 is permissive. It requires license and notice retention when you redistribute, and it does not impose the GPL copyleft requirement on derivative works.
Mixed-license stack: Your internal change control, patch policy and any vendor or contractor agreements should cover both license families, not just the one you read first.
Support and edition boundaries: The open-source license does not by itself define a paid support or feature tier. Ask Wazuh directly which features and support options you would buy separately, if any.

Before deployment, have counsel review how GPL-2.0 and Apache-2.0 apply to your modifications, agents deployed on third-party endpoints, and any managed service you plan to offer.

Where single sign-on, custom rules and compliance mapping sit

Single sign-on is the first place where the two platforms price differently. Elastic's self-managed subscription page places SAML and OpenID Connect single sign-on under the Enterprise subscription, so if your SOC analysts must sign in through your corporate identity provider, budget for that tier from the start rather than assuming it comes with the base product. Wazuh's supported identity options are not established in the facts we have for this comparison, so before you rely on any SSO path, confirm in the Wazuh documentation which protocols the dashboard supports, how role mapping works, and whether the setup needs a paid add-on. Ask both vendors to state this in writing against your identity provider, because a federation gap discovered after rollout forces local accounts and weakens your access review.

Custom detection work is where extensibility matters most to a team that will write its own rules. Wazuh ships over 3,000 built-in rules and decoders, and its ruleset is open for local rule and decoder files, so your engineers can tune alerts, add decoders for in-house applications and version those files alongside your infrastructure code. Elastic's custom detection content depends on tier and version: the detection engine sits under the Platinum subscription, which Elastic no longer sells to new customers, so confirm which current tier gives you rule authoring, exceptions and the rule types you need. Run a short test with one of your own log sources on each platform before you commit, and record who maintains the rules after go-live.

Compliance mapping needs the most care in this comparison. Wazuh documents mapping of its alerts to MITRE ATT&CK, which helps with detection coverage reporting, but that is not the same as a mapping to the control framework your assessor uses. If you need evidence against a specific standard, ask Wazuh which of its rule groups or dashboards map to the controls you care about, and treat any gap as work your team or DeployOpen would scope and document. For Elastic, this page does not establish compliance mappings beyond what Elastic's own documentation states, so confirm the specific framework coverage with Elastic and agree the evidence format with your auditor before you choose. Independent auditors and certification bodies, not the platform vendor or implementation partner, decide whether your controls satisfy a standard.

What drives running cost on each platform

Running cost for a self-hosted SOC is set less by the license line than by how much data you keep, how many agents report in, and how many people tune and patch the stack. The cards below separate one-time build work from recurring spend, and list what to request in writing from each vendor before comparing totals.

Storage retention and indexing volume

Retention period and daily event volume set the index footprint more than any other input. Wazuh and Elastic Security both store alerts and archived events in an OpenSearch-family or Elasticsearch-family index, so storage and search nodes grow with the number of days kept and the events per second ingested. Ask each vendor, and your own team, for a sizing worksheet that states the retention window for alerts and for raw archived events separately, plus the expected peak ingest rate.

Search nodes and hardware sizing

Compute and memory needs for the indexer, the manager or server tier and the dashboard are set by query load and retention. Wazuh's indexer is an open source fork of OpenSearch, so sizing guidance tends to follow OpenSearch practice, while Elastic Security sizing follows Elastic's own guidance for its cluster roles. Ask for the node count, roles, CPU, RAM and disk per role at your retention target, and confirm whether the vendor's recommendations were tested against your expected query volume.

Staff skills and on-call load

Most recurring cost is staff time. Running either stack means someone must operate the indexer cluster, write or tune detection rules, triage alerts and handle agent fleet issues around the clock. Teams already fluent in Elasticsearch query languages or Kibana may ramp faster on Elastic Security, while teams with Wazuh rule and decoder experience may find tuning simpler. Estimate the on-call rotation and the share of analyst hours spent on false positives before deciding.

Paid subscription tiers and licensing scope

Elastic's detection engine, machine learning anomaly detection and case management sit in the Platinum tier, which Elastic no longer sells to new customers, while endpoint malware and ransomware prevention, host isolation and SAML or OpenID Connect single sign-on sit under Enterprise. Wazuh's server and agent are GPL-2.0 and its indexer and dashboard are Apache-2.0, so the open components carry no license fee. Request an itemized quote that lists each tier, the features it covers, the node or resource basis for pricing, and the term length.

Upgrade and maintenance effort

Each platform moves across release lines on its own schedule, and every upgrade consumes test and change-window time. Wazuh 4.14.9 is the current 4.x release while a 5.0.0 release candidate is out, and Elastic 9.5.5 and 9.4.8 are current while 8.19.23 is still maintained. Plan for a parallel test cluster, a rollback path and a recurring budget line for upgrade work, and ask each vendor how long older lines receive fixes.

Support options and retainers

Community channels cost nothing but carry no response commitment. Vendor subscriptions bundle support into the license price, and third-party implementation partners, including DeployOpen, typically offer retainers for upgrades, continuous tuning and on-call coverage. Confirm in writing what response times, severity definitions and escalation paths are included, and whether an implementation partner's fixed-scope deliverables cover future upgrades or only the first deployment.

Endpoint and agent count

Agent count drives both the subscription basis where a vendor prices per endpoint and the volume of telemetry the back end must store. Wazuh agents cover Linux, Windows, macOS, Solaris, AIX and HP-UX, and existing OSSEC agents can report to a Wazuh server, which can lower migration cost on mixed estates. Count endpoints by operating system, confirm which agent types each platform needs for your fleet, and ask whether pricing changes at fleet growth thresholds.

How to move between Wazuh and Elastic Security

This sequence moves detection coverage from one stack to the other without a gap in monitoring, and it ends with a documented record of what was rebuilt, what was validated and what was retired. Confirm each vendor-specific step with the vendor before you commit to a cutover date.

Inventory agents, rules, alerts and retention
The security operations lead and the platform owner list every monitored host with its operating system, the agent type and version installed, and the log sources feeding each agent. They then export the active rules, alert categories, suppression lists, retention settings for each index or data stream, and the identity provider configuration used for dashboard access. The inventory is complete when every host and log source has an owner and every rule has a documented purpose. Ask the vendor which agent versions and operating systems the target platform supports before you finalize the list, since agent coverage differs between the two stacks. If the estate includes OSSEC agents, record their versions separately, because they are relevant to the compatibility step below.
Map existing detections to the target ruleset
Detection engineers take each rule in the inventory and find its equivalent in the target platform. Wazuh's ruleset ships over 3,000 built-in rules and decoders and maps alerts to MITRE ATT&CK, so teams moving toward Wazuh should check which custom rules still need a rebuild. Elastic's detection engine and machine learning anomaly detection sit in paid subscription tiers, so teams moving toward Elastic should confirm their subscription covers each rule type before mapping it. The output is a mapping table with one row per source rule, showing the target rule, the gap, and the owner who signed off. Rules with no equivalent go on a separate list for redesign rather than being silently dropped.
Run both platforms in parallel on a subset
The platform team deploys the target stack alongside the existing one and enrolls a small, representative group of endpoints in both, covering each operating system and host role in scope. Both stacks receive the same events during this period, so analysts can compare alert counts, false positives and missed detections side by side. Expect the parallel run to add load on the endpoints and the network, so confirm the agent resource overhead on your own hosts first. The step is complete when the team has a written comparison for each rule group and an agreed list of differences to resolve.
Migrate agents and rules in waves
The platform team moves endpoints in groups, starting with the lowest-risk segment and ending with the most critical systems. For each wave, they install or reconfigure the target agent, confirm the host appears in the new console, apply the mapped rules and retire the old agent on that host. Identity integrations, including single sign-on for dashboards, are reconfigured for each wave's administrators. Migrations for OSSEC estates may proceed differently: Wazuh documents that OSSEC agents are compatible with the Wazuh server, so mixed agents can report to one server during the transition. Each wave closes with a host-level checklist signed by the platform owner.
Validate alert fidelity against the baseline
Detection engineers replay known test activity, such as controlled events from an approved test or purple-team exercise, and confirm that the target platform raises the expected alerts with the expected severity. They compare volumes and false positive rates against the parallel-run baseline and record any rule that behaves differently. Response playbooks are rebuilt and tested in this step, including any active response actions that run on endpoints. The step is complete when each high-priority detection has a passing test record and each open difference has an owner and a decision.
Rebuild dashboards, access and response playbooks
Anything that does not transfer automatically is rebuilt in the target platform. Dashboards, saved searches, case workflows, single sign-on configuration and response playbooks are recreated and checked by the people who use them day to day. Confirm with the vendor whether saved objects, dashboard definitions or alert history can be exported and imported, since log data formats and stored objects are not automatically portable between the two stacks. The output is a rebuild register listing each artifact, its new location and the analyst who confirmed it works.
Decommission the old stack and archive data
Once validation is complete and the old agents are removed from every host, the team disables the old stack's collection, retains historical data according to the retention requirements recorded in the inventory, and archives it in a format that can be read after decommissioning. Access to the archive is restricted to named roles. The step closes when the old servers are shut down, the archive is verified by a restore test, and the change record is filed with the compliance owner. Confirm the archive format and the retention obligations with your compliance team and, where relevant, the vendor before deleting anything.

Where self-hosted SOC projects usually run long

Most Wazuh and Elastic Security projects run long in the same three places: agent rollout across mixed fleets, rule tuning, and storage sizing once real event volume arrives. Wazuh agents cover Linux, Windows, macOS, Solaris, AIX and HP-UX, so an inventory of operating systems, versions and change windows should exist before the first agent is pushed. Ask the team to list every host class, including legacy and isolated systems, and to confirm which agent versions each one can run. Elastic Agent and its policies raise the same question on the Elastic side. Plan the rollout in waves so the Wazuh server and indexer see realistic load before the whole estate reports in.

Rule tuning is the second long stretch. Wazuh ships over 3,000 built-in rules and decoders mapped to MITRE ATT&CK, and every one of them can fire on your data. Expect a period where analysts triage noisy alerts, suppress known-good activity and document each change so an auditor can trace why a rule behaves as it does. On the Elastic side, the detection engine sits in the Platinum or Enterprise subscription tiers, so confirm which tier your team will buy before tuning begins, because detection content and its workflow depend on that decision. Storage is the third. Index sizing, retention and archiving should be modeled on measured event rates from a pilot, not on vendor minimums.

Two decisions can stall a project if they are left open. Identity wiring, including single sign-on for the dashboard and role mapping, needs confirmed support in the edition you choose, and procurement for paid Elastic features can take longer than the technical work. Wazuh 5.0.0 was published as a release candidate on October 5, 2026, so production plans should target the 4.x line, currently 4.14.9, until your team confirms the 5.x release and its upgrade path. Ask both vendors in writing which features need a paid tier, how upgrades across major release lines are supported, and which versions will be maintained for your planned operating period. Wazuh release notes is the place to check the current 4.x status.

Questions buyers ask before choosing or hiring help

What drives the cost of Wazuh and Elastic Security, and what should I ask for in a quote?

The software licenses differ most. Wazuh server and agent are GPL-2.0 with an OpenSSL linking exception, and the Wazuh indexer and dashboard are Apache-2.0, so there is no license fee to pay for the core platform. Elastic's detection engine, machine learning anomaly detection and case management sit under the Platinum subscription, which Elastic no longer sells to new customers, while endpoint malware and ransomware prevention, host isolation and SAML or OpenID Connect single sign-on sit under Enterprise, according to Elastic's subscriptions page. Your recurring costs then come from infrastructure for the indexer or search nodes, storage retention, and support or retainers. Ask any quote to split one-time build work from recurring operations, to name the Elastic tier each required feature needs, and to list the storage sizing assumptions behind the infrastructure line. Confirm current Elastic pricing directly with Elastic, since DeployOpen does not publish a price list and quotes follow from the written scope.

How long does a self-hosted SOC rollout usually take?

The honest answer depends on scope, so no duration is stated here. The main drivers are the number of endpoints and operating systems to enroll (Wazuh agents support Linux, Windows, macOS, Solaris, AIX and HP-UX), how many custom rules and decoders you need beyond the built-in set, the number of log sources to onboard, your compliance evidence requirements, and how many change windows your team needs. Elastic rollouts add time when you need Enterprise features and their integration into your identity provider. Ask any implementation partner for a written timeline tied to a fixed scope, with each deliverable and dependency listed, and confirm the assumptions about hosts and data sources in writing before work starts.

What does the work need from our own team?

Expect to commit named people from several areas. Security engineers decide detection priorities and tune rules, platform or infrastructure engineers provision the indexer, server and dashboard, and identity administrators configure single sign-on. Data owners confirm which logs are in scope and how long they must be kept. You will also need access to endpoints for agent deployment, approval for network paths between agents and the server, and scheduled change windows for agent rollouts and upgrades. Ask the vendor or partner to list each role, its time commitment and the access it requires before the scope is signed.

Can an in-house team run this without outside help?

Yes, if your team already runs Linux services, has experience with search clusters and can staff detection engineering. Wazuh's ruleset ships over 3,000 built-in rules and decoders and maps alerts to MITRE ATT&CK, which gives a capable team a working starting point. Outside help is most useful for initial architecture, hardening, backup and upgrade planning, custom content, and evidence preparation for compliance assessments. DeployOpen plans, implements, hardens, backs up, upgrades and documents self-hosted platforms in your own infrastructure, and runs ongoing support as a retainer. It does not issue audit reports or certifications, so independent auditors remain responsible for those.

Does Wazuh's GPL license change what we owe for internal use?

For internal use, GPL-2.0 generally does not require you to publish your modifications, because the obligations are triggered by distribution. If you ship Wazuh server or agent binaries, or a modified version, to customers or other third parties, you take on source-availability and license notice duties. The Wazuh indexer and dashboard are Apache-2.0, which carries different notice requirements. Your counsel should confirm how these terms apply to your deployment model, including managed service delivery to affiliates. Read the Wazuh LICENSE file in the wazuh/wazuh repository before relying on this summary.

Can Elastic Security run without Enterprise features?

Elastic's source code is available under three licenses, Elastic License 2.0 as the default distribution, SSPL 1.0 and AGPLv3, so the engine itself is not locked behind a subscription. The features you may need for a SOC, however, sit in paid tiers. The detection engine, machine learning anomaly detection and case management are listed under Platinum, which Elastic no longer sells to new customers, and endpoint malware and ransomware prevention, host isolation and SAML or OpenID Connect single sign-on are listed under Enterprise. Map each control you need to a tier and confirm the current entitlement with Elastic before you choose a design.

How do we handle an existing OSSEC estate?

You do not have to replace agents on day one. The Wazuh team forked OSSEC in 2015, and OSSEC agents are compatible with the Wazuh server, so mixed OSSEC and Wazuh agents can report to one Wazuh server during a staged migration, according to Wazuh's migration guide. The Wazuh documentation page on migrating from OSSEC is the natural next read, and the OSSEC repository publishes release history, with 4.4.0 released on October 5, 2026. Plan the migration in waves by host group, validate alert parity and ruleset coverage on each wave, and keep rollback steps for each change window.

What changes if the SOC must run air-gapped?

The architecture stays the same, but the delivery work grows. Every package, container image, rule update, documentation set and agent installer must be mirrored into the enclave through an approved transfer path, and the update process must be planned around that path. Confirm with each vendor that your chosen components and rule feeds can be updated offline, and check the license terms of each component before mirroring. Security Onion documents a distributed deployment of manager, search and sensor nodes, which you should size against your own traffic and storage. Ask any partner to define how updates, backups and evidence collection work without internet access.

How DeployOpen helps choose, implement or migrate

DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For Wazuh vs Elastic Security, we start by mapping your agent estate, log sources, compliance obligations and licensing constraints before recommending a platform or a migration path.

How we scope

Inventory endpoint operating systems, agent counts and log sources to test coverage against each platform.
Document which detection, machine learning and endpoint prevention features your team needs, and which edition they require.
Agree the written scope, deliverables and timelines in writing before any work starts, as most engagements are fixed-scope.

How we build

Deploy the chosen stack inside your infrastructure, with indexer, server, dashboard and agent roles defined for your environment.
Map Wazuh ruleset coverage or Elastic detection rules to the controls your compliance assessment references, then tune them.
Run security testing against the deployed monitoring pipeline to confirm alerts fire for the scenarios you care about.

How we hand over

Provide runbooks for agent enrollment, rule updates, index storage management and license-tier decisions.
Deliver documentation of architecture, configuration and evidence so your internal team and auditors can follow the setup.
Train your operators on triage workflows so the SOC can run the platform without depending on us day to day.

How we support

Offer ongoing support, upgrades and continuous testing as a retainer, scoped to your release cadence.
Plan version upgrades and migrations, such as moving agents between Wazuh releases or from an existing OSSEC estate, as a separate written scope.
Confirm with the vendor and your own environment which features your licence terms permit before each change.

Wazuh vs Elastic Security