Wazuh vs Elastic Security: when each platform fits
Choose Wazuh when your main problem is endpoint visibility and you want a SIEM with agents, a ruleset and compliance dashboards included from the start. Its server and agents are licensed under GPL-2.0 with an OpenSSL linking exception, and its indexer and dashboard are Apache-2.0, so the core platform carries no license fee to plan around. Wazuh ships more than 3,000 built-in rules and decoders, maps alerts to MITRE ATT&CK, and includes dashboard views for PCI DSS, GDPR, HIPAA and NIST 800-53. Teams with a mixed Linux, Windows and macOS fleet, and teams that want file integrity monitoring and vulnerability detection without assembling them separately, usually land here. Wazuh 4.14 is the current 4.x line, so confirm the agent versions and operating systems in your fleet against the release notes before you commit.
Choose Elastic Security when you already run Elasticsearch and Kibana and your analysts do most of their work in search, Timeline and Cases. Elastic Security adds SIEM detections, prebuilt and custom rules, machine learning anomaly detection and entity analytics on the same stack, and Elastic Agent with Elastic Defend covers endpoints. The prevention features are where the license decision bites: endpoint malware and ransomware prevention, host isolation and SAML or OpenID Connect single sign-on sit in the Enterprise tier, and Platinum is no longer sold to new self-managed customers. Elastic's default distribution is under the Elastic License 2.0, and its licensing FAQ notes that AGPLv3 is offered as an OSI-approved option for the source code, so confirm which license your legal team will accept.
The decision turns on four questions. First, licensing posture: a GPL-2.0 core against an Elastic subscription that gates prevention and SSO, so price the Enterprise tier before you compare features. Second, which features you must have: if host isolation or SSO is a hard requirement, Elastic's paid tier is part of the baseline, while Wazuh's agent-based response is a different control set, so verify each capability in writing. Third, agent coverage: confirm your operating systems against both agent lists. Fourth, in-house skills: Elastic clusters need Elasticsearch node-role planning and at least three master-eligible nodes for high availability, while Wazuh asks for indexer and server operations knowledge. If you have no Elasticsearch staff, the search-first model is a cost, not a benefit.
Which platform fits which scenario
This table matches common team situations to the platform that fits better and the condition that makes it so. Read each row as a starting point, then confirm the condition against your licensing, hosting and staffing position before you shortlist.
| Scenario | Better fit | Condition that decides it |
|---|---|---|
| Regulated team needing file integrity monitoring and compliance dashboards | Wazuh | Wazuh includes file integrity monitoring and prebuilt dashboard views for PCI DSS, GDPR, HIPAA and NIST 800-53 under GPL-2.0, while those capabilities need to be built or confirmed on the Elastic side. |
| Team already running Elasticsearch and Kibana at scale | Elastic Security | Your existing cluster, data tiers and staff skills carry over, so the question becomes which paid Elastic tier covers the detection and endpoint features you need. |
| Mandate for OSI-approved open source licensing | Wazuh | Wazuh server and agent are GPL-2.0 and the indexer and dashboard are Apache-2.0, whereas the default Elastic distribution is under the Elastic License 2.0, which is not OSI approved (confirm the AGPLv3 option with Elastic if you need it). |
| Endpoint prevention, malware and ransomware blocking, and host isolation | Elastic Security | Elastic lists these under its Enterprise tier, so budget for that subscription; Wazuh focuses on detection, active response and vulnerability detection, so confirm whether its active response meets your blocking requirement. |
| Mixed Linux and Windows fleet with macOS endpoints | Wazuh | Wazuh agents cover Linux, Windows and macOS, and agent-based coverage can be extended to devices through syslog collection; confirm the agent versions and features your OS mix needs. |
| Need for paid SSO and role-based access in a self-managed deployment | Depends on tier | Elastic places SAML and OpenID Connect single sign-on under Enterprise, so self-managed buyers need that tier; confirm Wazuh single sign-on support against your identity provider in the Wazuh documentation. |
| Small team wanting one agent for logs, metrics and security | Elastic Security | Elastic Agent is one agent managed through Fleet for logs, metrics and endpoint protection, which reduces the agent count if you already accept the Elastic subscription model. |
| Team that wants a prebuilt ruleset mapped to MITRE ATT&CK out of the box | Wazuh | Wazuh ships over 3,000 built-in rules and decoders mapped to MITRE ATT&CK, whereas Elastic detection content is delivered through the Kibana detection engine and its paid tiers for some features. |
How Wazuh and Elastic Security are built and deployed
Wazuh and Elastic Security both store security data in an Elasticsearch-family search backend, but they assemble it differently. The cards below cover the components you will run, how each platform scales and stays available, and what that means for upgrades, support and staffing after go-live.
Wazuh's four components
Wazuh runs as an indexer that stores alerts, a server that decodes and analyzes agent data, a dashboard, and agents on endpoints. Each component is a separate thing to patch, back up and monitor. Ask who on your team owns each one, and confirm which operating systems your endpoint estate needs the agent to cover before you size the rest.
Wazuh indexer as an OpenSearch fork
The Wazuh indexer is an open source fork of OpenSearch, so its search and storage model differs from Elasticsearch in its own way. Your operators need OpenSearch-style administration skills, and any Elasticsearch-specific tooling or plugins you already run may not carry over unchanged. Confirm the fork's compatibility with the integrations you plan to use.
Elastic Security on Elasticsearch and Kibana
Elastic Security runs its detection engine, Timeline and Cases on Elasticsearch and Kibana, and it can run on Elastic Cloud or self-managed infrastructure. Because the search tier is the same product family your analysts may already know, the skills gap can be smaller, but the cluster itself becomes a larger sizing and tuning job. Confirm which features you need, since some sit in paid self-managed tiers.
Elastic Agent managed through Fleet
Elastic Agent is one agent that collects logs, metrics and security data and runs Elastic Defend, and Fleet manages its policies centrally. Fewer agents on each host simplifies rollout, but policy changes now flow through Fleet and its server, which becomes a dependency for every endpoint. Check how your change control handles Fleet policy versions before you commit.
Cluster roles and the three-master minimum
Elasticsearch separates node roles such as master-eligible, data tiers, ingest and coordinating-only, and a highly available cluster needs at least three master-eligible nodes. Wazuh offers its own cluster model, with the indexer and a server cluster for horizontal scaling. Build a node-role map for each platform and count the hosts, storage and patching windows that high availability adds.
Kubernetes deployment and version support
Elastic provides Elastic Cloud on Kubernetes for Elasticsearch, Kibana, Elastic Agent and other components, offered in Basic and Enterprise tiers. Wazuh documents Kubernetes deployment as well, so the comparison turns on which operator and release cadence your platform team will follow. Confirm the supported Kubernetes versions, storage classes and upgrade path with each vendor before you design the cluster.
Capability, license and tier differences side by side
This table sets Wazuh and Elastic Security against each other on license, agent coverage, detection content, file integrity and vulnerability detection, compliance views, single sign-on, FIPS and endpoint prevention. Read the rows where the Elastic cell names a tier as the cost question: the features listed there are paid features, and the entries marked for confirmation need a check against the current subscription terms and your own environment before you decide.
| Capability | Wazuh | Elastic Security |
|---|---|---|
| License | Server and agent under GPL-2.0 with an OpenSSL linking exception; indexer and dashboard under Apache-2.0 | Default distribution under Elastic License 2.0; SSPL 1.0 and AGPLv3 also offered for source code; ELv2 and SSPL are not OSI-approved |
| Agent coverage | Linux, Windows, macOS, Solaris, AIX and HP-UX agents; agentless syslog and API collection for devices like firewalls | Single Elastic Agent with Elastic Defend for endpoint protection, managed centrally through Fleet; confirm OS coverage for your fleet |
| Built-in detection content | Over 3,000 built-in rules and decoders, with alerts mapped to MITRE ATT&CK | Prebuilt detection rules from the elastic/detection-rules repository, delivered automatically to the detection engine; confirm rule coverage for your log sources |
| Detection engine and ML | Rules, decoders and custom rules are included in the open platform | Detection engine is in the Enterprise tier for self-managed buyers; ML anomaly detection alerting is on Platinum and Enterprise, and Platinum is closed to new customers |
| File integrity and vulnerability detection | File integrity monitoring and vulnerability detection correlate agent software inventory with the Wazuh CTI platform or an offline repository | Elastic Security documents host telemetry and detections; confirm whether file integrity and vulnerability features match your requirements in the current subscription terms |
| Compliance dashboards | Prebuilt dashboard views for PCI DSS, GDPR, HIPAA and NIST 800-53 | Compliance views depend on the rules and dashboards you deploy; confirm framework coverage with Elastic before you rely on it |
| Single sign-on | Wazuh single sign-on is documented in the user administration guide; confirm the protocols and edition that apply to your version | SAML and OpenID Connect single sign-on are listed under the Enterprise tier for self-managed deployments |
| FIPS and encryption at rest | Confirm FIPS mode and encryption at rest against your Wazuh version and hardening plan | FIPS 140-3 mode and encryption at rest support are listed among security features on the self-managed subscription page; confirm the tier that includes them |
| Endpoint prevention and host isolation | Active response and file integrity alerting; confirm what automated responses are available in your deployment | Malware and ransomware prevention, memory threat protection and host isolation are listed under the Enterprise tier |
| Release line | Wazuh 4.14.9 released October 14, 2026; Wazuh 5.0.0 release candidate published October 5, 2026 | Elastic 9.5.5 and 9.4.8 released October 6, 2026; 8.19.23 still maintained; core 9.x maintenance ends October 15, 2027 |
What is free, what is paid and what the licenses allow
Wazuh's server and agent code is licensed under GPL-2.0 with an exception that permits linking with OpenSSL. The Wazuh indexer and dashboard are licensed under Apache-2.0. Both licenses are OSI-approved open source licenses, so the core platform carries no license fee and no tier gate on its detection logic. Costs come from the infrastructure you run it on, the staff who operate it and any outside support you buy.
- Server and agent: GPL-2.0 with the OpenSSL linking exception, which governs changes you make and redistribute.
- Indexer and dashboard: Apache-2.0, a permissive license that also suits embedding in internal tooling.
- Ruleset: The built-in rules and decoders are part of the open platform, not a separate paid edition.
- Release line: Wazuh 4.14.9 is the current 4.x release, and a Wazuh 5.0.0 release candidate exists, so confirm which line your standards and upgrade plan target.
- Commercial services: Wazuh Cloud is a separate managed offering. Check its terms directly if you want a managed option.
Before you commit, confirm the license terms with Wazuh and your legal team against the exact release you will deploy.
Elastic Security runs on Elasticsearch and Kibana and sells its security features through self-managed subscription tiers. The Basic tier is free and open. Platinum lists the detection engine, machine learning anomaly detection and case management, but Elastic no longer sells it to new customers. Enterprise includes endpoint malware and ransomware prevention, host isolation and SAML or OpenID Connect single sign-on. A new self-managed buyer who needs those paid features therefore looks at Enterprise, or at Elastic Cloud.
- Basic: Free and open, with TLS, the file and native user realms and role-based access control.
- Platinum: Detection engine, anomaly detection and case management, closed to new self-managed buyers.
- Enterprise: Endpoint malware and ransomware prevention, host isolation and SAML or OIDC single sign-on.
- Anomaly alerting: Alerting rules based on anomaly detection are limited to Platinum and Enterprise.
- Subscription terms: Ask Elastic for the current tier matrix, pricing and what your specific detection and endpoint features map to.
Check the tier that maps to each feature you need before you design the architecture, and confirm that the list still matches Elastic's subscriptions page at the time of purchase.
Elasticsearch and Kibana source code is available under three licenses: the Elastic License 2.0, which is the default distribution, SSPL 1.0 and AGPLv3. Elastic says the default has been under ELv2 since 2021 and that AGPLv3 was added in September 2024, before the 8.16 release, to offer an OSI-approved open source option. ELv2 and SSPL are not OSI-approved open source licenses. ELv2 also forbids offering the software to others as a hosted or managed service, which matters if you plan to resell security monitoring.
- Default distribution: ELv2 governs the default build most teams download.
- OSI status: Only the AGPLv3 option is OSI-approved, so an OSI requirement points to that option.
- Managed-service limit: ELv2 restricts providing the software as a managed service to third parties.
- Derivative use: Internal use and self-hosting for your own organization is the usual pattern these terms allow.
- Confirm: Ask Elastic which license applies to the exact package and version you plan to run.
Have counsel confirm how these terms apply to your deployment model, especially if a managed provider will operate the stack for you.
The two platforms differ most sharply on OSI status. Wazuh's server, agent, indexer and dashboard are licensed under GPL-2.0 or Apache-2.0, both OSI-approved. Elastic's default ELv2 is not OSI-approved, so a Elastic deployment built on the default distribution does not meet an OSI-approved open source requirement. Elastic's AGPLv3 option does meet that requirement, but the paid security features sit in Enterprise tiers regardless of which source license you use.
- Wazuh: GPL-2.0 and Apache-2.0, both OSI-approved.
- Elastic default: ELv2, not OSI-approved, with a managed-service restriction.
- Elastic alternative: AGPLv3 is OSI-approved and available as a source option.
- Paid features: License choice does not remove tier gates on detection, endpoint and SSO features.
- Policy check: If your procurement policy names OSI approval, verify which Elastic license covers your chosen build.
Record the license under which each platform will be deployed in your architecture decision, and confirm it against your organization's open source policy.
What drives running cost on each platform
This table sets out the cost components for a self-hosted Wazuh deployment against a self-managed Elastic Security deployment, showing who gets paid, what recurs and what drives each cost up. Read it as a checklist for a written quote: the license line is only one part of the total, and storage, tuning and staffing usually decide the difference.
| Cost driver | Wazuh | Elastic Security (self-managed) |
|---|---|---|
| License fees | No license fee for the GPL-2.0 server and agents or the Apache-2.0 indexer and dashboard. Confirm with the vendor which components, if any, you would buy as support. | Free and open (Basic) tier covers the core stack, but detection engine, machine learning anomaly detection and case management sit in Platinum, which is no longer sold to new customers. Endpoint malware and ransomware prevention, host isolation and SAML or OpenID Connect single sign-on sit in Enterprise, so budget a recurring subscription for those features. |
| Storage and indexer sizing | The Wazuh indexer is an OpenSearch fork that stores alerts. Disk growth follows endpoint count, log volume and retention, so ask the vendor for its sizing guidance per device type. | Elasticsearch data nodes hold alerts and events. Hot, warm, cold and frozen tiers can lower storage cost, but confirm which tiers your subscription level allows before you size the cluster. |
| Cluster nodes and high availability | Server clustering and a multi-node indexer add hosts. Each extra node is recurring infrastructure, whether on your cloud account or in your data center. | A highly available cluster needs at least three master-eligible nodes per the node roles documentation, plus data, ingest and Kibana capacity. Those nodes recur on every month of operation. |
| Rule tuning and content | The ruleset ships over 3,000 built-in rules and decoders mapped to MITRE ATT&CK. Recurring effort goes into suppressing noisy rules and adding custom decoders for your own applications. | Prebuilt detection rules come with the detection engine, and rules are updated automatically from the detection-rules repository. Recurring effort goes into tuning, exception handling and alert suppression, and a paid tier is needed to use the detection engine in self-managed deployments. |
| Staff skills | Operators need Linux, the indexer, server and dashboard administration, and agent deployment at scale. Ask who will own upgrades across the four components. | Operators need Elasticsearch cluster administration, Kibana, Fleet and Elastic Defend policy management. Confirm whether your team already runs Elastic, because that lowers ramp-up time. |
| Support options | Support and managed options are offered separately from the open-source components. Ask for the written scope, response targets and whether upgrades are included. | Support is tied to the subscription tier, so ask Elastic which tier includes which support and whether response times are written into the contract. |
| Upgrade and lifecycle effort | Wazuh 4.14 has shipped frequent patch releases, so plan a recurring patch window. Wazuh 5.0.0 is at release candidate stage, so ask how a major upgrade would be handled. | Elastic lists end of maintenance dates by line, including 8.x on January 15, 2027 and 9.x on October 15, 2027, so plan a version path before those dates. Upgrades often touch the cluster and Elastic Agent policies at once. |
| One-time versus recurring | One-time: design, deployment, initial rule tuning and integration work. Recurring: infrastructure, patching, rule maintenance and staff time. | One-time: design, cluster build, migration of detections and integration work. Recurring: subscription, infrastructure, rule maintenance and staff time. |
| What to request in a written quote | Itemized scope for deployment, indexer sizing for your agent count and retention, the upgrade plan, and whether rule tuning and support are included. | Subscription tier and features by name, node count and roles, storage and retention assumptions, renewal terms and end-of-life plan for the chosen version line. |
Moving from one platform to the other
This sequence shows how a team moves SIEM and endpoint coverage between Wazuh and Elastic Security in either direction, and it ends with a documented cutover that both platforms can be audited against. Each step names what transfers, what must be rebuilt, and the check that confirms the step is finished.
Inventory sources, rules and access before moving
The team lists every log source, agent group, custom rule, decoder or detection rule, dashboard, saved search, role and SSO mapping on the current platform. Someone who owns security operations and someone who owns identity should sign off together, because access mappings often differ between the two products. The step is done when the inventory has an owner and a target equivalent for each item, and any item without an equivalent is flagged for a decision.
Decide what data moves and what restarts
Alerts and events already stored in the old indexer are usually kept by exporting them to archive storage, while new data starts flowing to the new platform on day one. Historical data does not convert into a new index format on its own, so the team should confirm with the vendor and its own environment whether a bulk export or re-ingest path is practical for the volume involved. The step is complete when the retention requirement for each data type is written down and matched to an archive or a clear decision to start fresh.
Re-create detection logic on the target platform
Wazuh rules and decoders are written in XML and do not load into Elastic's detection engine, and Elastic detection rules are not a drop-in set for Wazuh. Each rule is mapped by intent: the security team rewrites the logic, tests it against replayed or sample events, and tunes thresholds to the new data shape. Elastic's prebuilt rules are maintained in the elastic/detection-rules repository and arrive automatically, so teams moving to Elastic should compare those against their custom Wazuh rules instead of copying them. The step is done when every retained rule has a tested equivalent or a documented reason for retirement.
Redeploy agents and endpoint coverage
Wazuh agents and Elastic Agent with Elastic Defend are different software with different enrollment, policy and upgrade paths, so each endpoint is re-enrolled rather than converted. Teams move one host group at a time, uninstall the old agent after the new one reports, and check that file integrity monitoring, vulnerability inventory or endpoint protection settings match the previous policy. Endpoint protection features such as host isolation sit in a paid Elastic tier, so the team confirms licensing before a group is switched. The step is done when every endpoint shows as reporting on the new platform and the old agent has been removed.
Rebuild dashboards, reports and compliance views
Wazuh dashboards and its prebuilt compliance views do not export as Kibana objects, and Elastic dashboards are not automatically the same as Wazuh's compliance pages. Analysts recreate the views that drive daily triage and any reporting that an auditor will request, mapping each report to the control evidence it supports. An auditor or compliance lead reviews the rebuilt reports against the previous set. The step is done when each required report produces the same evidence on the new platform, or the gap is recorded for remediation.
Rebuild identity integration and role mapping
Single sign-on, group-to-role mapping and access controls are configured again on the target platform, because the two products handle them in different ways. On Elastic, SAML or OpenID Connect single sign-on is a paid Enterprise feature, while the Wazuh single sign-on path is documented separately, so the team confirms the identity provider settings with each vendor before cutover. Test users from each role log in and see only the data their role allows. The step is done when every role has been tested end to end and no account relies on a local password that was not approved.
Run both platforms in parallel during cutover
Both systems receive the same endpoint and log sources for a defined overlap period, and the team compares alert volume, detection coverage and analyst workflow across them. Differences in noise, missed events or delayed alerts are logged and fixed before the old platform stops receiving data. Teams should set the overlap length against their own change control process, since no standard duration applies to every environment. The step is done when the cutover criteria agreed at the start are met and the sign-off record shows who accepted them.
Retire the old platform and keep its evidence
After cutover, the old indexer, server and agents are shut down, and the exported archives, rule history and configuration backups are stored where the retention policy requires. Keeping the exported evidence matters for investigations and for compliance assessments that look back at earlier periods. Licenses and subscriptions are cancelled only after the archive is confirmed readable. The step is complete when the archive has been restored in a test and the decommissioning record is signed.
Where implementation projects usually run long
The longest delays usually come from sizing and data decisions made before any agent is installed. On Wazuh, the four components are the indexer, server, dashboard and agents, and the indexer stores alerts, so storage and node count must be sized against the endpoint count and retention you commit to. Wazuh's server can run as a cluster, and the deployment options range from an all-in-one host to a distributed layout. On Elastic Security, the Elasticsearch node roles (master-eligible, data tiers, ingest, machine learning) each need planning, and a highly available cluster needs at least three master-eligible nodes. Ask both vendors for a documented sizing method tied to your events per second, retention and hot, warm and cold tiers, and confirm it in a proof of concept before you commit to hardware.
Identity and rollout work is the next common source of slippage. Wazuh documents SSO on its own user administration pages, while Elastic's SAML and OpenID Connect single sign-on sits under the Enterprise tier, so the identity decision can change the license you buy. Agent rollout across Linux, Windows and macOS hosts, plus any Solaris, AIX or HP-UX systems, needs group-based configuration, change windows and a plan for hosts that cannot take an agent. Rule tuning is often the largest unplanned effort: Wazuh ships over 3,000 built-in rules and decoders, and Elastic ships prebuilt detection rules that are customized per environment. Budget time for suppressing false positives on both sides, and confirm who on your team owns that work after go-live.
Upgrade cadence and retention policy decide the run cost after launch. Wazuh 4.14 received patch releases on 17 March, 23 April, 1 July, 29 July, 23 September and 14 October 2026, so your team should expect frequent patch windows and test each one against custom rules and decoders. Elastic publishes end-of-life dates per line: the core stack 9.x line reaches end of maintenance on October 15, 2027, and 8.x on January 15, 2027, with 8.x support ending July 15, 2027. Confirm which line your deployment will run, when you plan to move between lines, and how long you must keep archived data, because long retention on hot storage is a frequent cause of re-platforming delays.
What buyers ask before choosing Wazuh or Elastic Security
Does Wazuh need a paid tier for SSO or prevention?
The supplied facts do not list a paid tier for Wazuh's server or agent features, but confirm single sign-on, support terms and any add-on modules with Wazuh before you commit. Wazuh documents its single sign-on setup in the user administration guide, so check that it fits your identity provider. Elastic is different. SAML and OpenID Connect single sign-on, malware and ransomware prevention and host isolation sit under the Enterprise tier, and the Platinum tier that held detection and case management is closed to new customers. When you compare, list which prevention actions each platform blocks and which it only alerts on, because Wazuh's file integrity monitoring and active response do not work the same way as Elastic Defend.
What does Elastic Security cost to run, and what drives it?
Elastic Security's cost depends on the subscription tier, the hosting model and the volume of data you keep, and the supplied facts give no price for any tier. Self-managed buyers of paid security features now choose between Basic and Enterprise, or move to Elastic Cloud, because Platinum is no longer sold to new customers. Recurring costs include the subscription, storage for indexed events and retention, and cluster nodes. A highly available Elasticsearch cluster needs at least three master-eligible nodes, and hot, warm, cold and frozen data tiers change the storage mix. Staff time for rule tuning and upgrades also recurs. Ask for a quote that separates subscription, infrastructure, storage and services, and state your endpoint count and retention period.
How long does a self-hosted Wazuh or Elastic Security deployment take?
No supplied fact gives a duration for either deployment, so treat any timeline as something to confirm in writing. The main variables are endpoint count, the install method, retention requirements and how many detections need tuning. Wazuh documents several install paths, including a prebuilt OVA appliance, an Amazon Machine Image, Docker, Kubernetes, Ansible, Puppet and an offline guide, and each path changes the work involved. Elastic Security adds cluster sizing, Elastic Agent rollout through Fleet and Elastic Defend policy design. DeployOpen works to a fixed scope agreed in writing before work starts, so any timeline it gives follows from that written scope and the environment it is given.
What does a Wazuh or Elastic Security rollout need from our team?
Both platforms need staff who can run a search backend, manage agents at scale and triage alerts. For Wazuh, the team needs Linux administration, agent management, rule tuning, and operation of the indexer and dashboard, which are separate components from the server. For Elastic Security, add Elasticsearch node roles, Kibana administration, Elastic Agent policy design and, if you run Kubernetes, the Elastic Cloud on Kubernetes operator. Your team also owns the detection content it relies on and needs a change process for upgrades. Wazuh shipped six 4.14 patch releases in 2026 according to its release notes, so plan for regular patching on either platform.
Can our team run either platform without an implementation partner?
Your team can run either platform without a partner if it has the skills described above and enough time to keep the platform patched, tuned and monitored. Both are self-hosted, and both publish installation paths, so an in-house build is workable where operations staff are funded for the long term. DeployOpen plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside the client's own infrastructure. Most engagements are fixed-scope, and ongoing support, upgrades and continuous testing are available as retainers. Whichever route you choose, ask what runbooks, configuration and knowledge transfer you will receive at handover.
Which Elastic Security features are free in the Basic tier?
Elastic's Basic tier includes TLS, the file and native user realms and role-based access control, which Elastic made free with Elasticsearch 6.8.0 and 7.1.0 on May 20, 2019. Single sign-on, Active Directory and LDAP authentication, and field- or document-level security stayed in paid tiers, according to Elastic's announcement. The detection engine, machine learning anomaly detection and case management sit under Platinum, and endpoint prevention and SAML or OpenID Connect single sign-on sit under Enterprise. Confirm the current tier table on Elastic's subscriptions page before you buy, because tier contents can change. Even on paid tiers, you still need your own detection content and response process.
Can we replace Elastic Security with Wazuh later?
Moving from Elastic Security to Wazuh later is possible, but it is a full migration with several parts. Wazuh's indexer is an OpenSearch fork, so any Elastic-specific storage, index and query assumptions need review. Agents also change, because Elastic Agent and Elastic Defend would be replaced by Wazuh agents on each endpoint. Detection content needs rework too. Elastic's detection rules are published under the Elastic License v2 in the detection-rules repository, and Wazuh rules and decoders are a separate set that you must map to your use cases. Plan for parallel running, retention of historical data in the old system and an agreed cutover date. Confirm export formats and data retention terms with both vendors before you commit.
How DeployOpen helps choose, implement or migrate
DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure, so the choice between Wazuh and Elastic Security can be tested against your environment before anything is committed. Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
How we scope
- Written scope names which endpoints, operating systems and log sources the Wazuh or Elastic Security deployment must cover.
- Scope records the licensing position you need, including whether Elastic Enterprise features such as host isolation are required.
- Scope states the search backend, storage retention and the hosting model you have approved in your own cloud or data center.
How we build
- Build covers installation, agent rollout, decoder and rule work, and SSO integration against your existing identity provider.
- Testing checks alert paths, agent coverage and active response behavior on representative hosts before production use.
- Sizing notes record node counts, storage per device type and the high availability design the chosen platform needs.
How we hand over
- Handover documents the architecture, upgrade path and configuration, so your team can operate the platform after go-live.
- Compliance evidence packs map configured controls to the frameworks you name, prepared for your independent auditors to review.
- Runbooks cover agent upgrades, index lifecycle, backup and restore, and what to confirm with the vendor before each release.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- Retainers can cover patch review for the Wazuh 4.14 line or the Elastic release lines your environment runs.
- Support scope is agreed in writing, so response expectations and included upgrades are clear before you sign.
