Wazuh vs OSSEC: which to choose

Wazuh vs OSSEC: when each one fits a self-hosted estate

Choose OSSEC alone when your estate is small, changes slowly, and already has a log pipeline and search tool that your team trusts. OSSEC is a GPL-2.0 host intrusion detection system that covers log analysis, file integrity checking, policy monitoring, rootkit detection, real-time alerting and active response. Those functions run on each host, and the 4.x line is still maintained, with OSSEC 4.4.0 published on October 5, 2026. If you already forward OSSEC alerts into a SIEM your SOC uses, adding another central server may duplicate work rather than reduce it.

Move toward Wazuh when you need a central view that OSSEC does not provide on its own. Wazuh is a fork of OSSEC made in 2015, and its four central components are the indexer, server, dashboard and agents. The indexer is an open source fork of OpenSearch, and the dashboard gives analysts search and reporting across all agents. Wazuh also ships over 3,000 built-in rules and decoders, maps alerts to MITRE ATT&CK, and adds vulnerability detection. Before you plan the move, confirm which of these capabilities your compliance evidence requires, since the vulnerability and ATT&CK mapping features are the ones most often cited in assessments.

Three decision drivers settle most of this choice. First, how much central search and reporting you need: if analysts only read alerts on a few hosts, OSSEC may be enough, but if you need one place to query every endpoint, Wazuh's indexer and dashboard are the case for the move. Second, whether an existing SIEM already exists, because feeding Wazuh alerts into a second platform adds cost and a second system to patch. Third, how much operating effort your team can absorb, since running the indexer, server and dashboard is a recurring job that OSSEC does not require. Mixed estates are supported, because OSSEC agents can report to a Wazuh server, so you can migrate in stages.

Which platform fits which scenario

This table maps common Wazuh vs OSSEC situations to the platform that usually fits better and the condition that decides it. Read each row against your estate: the fit depends on whether you need a central console, ATT&CK-mapped alerting and vulnerability detection, or only host telemetry feeding an existing SIEM.

Scenario	Better fit	Condition that makes it so
Existing OSSEC estate with no central console	Wazuh (migrate in stages)	Wazuh adds the indexer, server and dashboard, and OSSEC agents can report to a Wazuh server, so you can move the manager without replacing every agent at once. Confirm your agent versions and rules against the migration guide first.
Team wants ATT&CK-mapped alerts and vulnerability detection out of the box	Wazuh	The Wazuh ruleset ships over 3,000 built-in rules and decoders and maps alerts to MITRE ATT&CK. OSSEC does not provide the same packaged dashboard and vulnerability features, so this need points clearly to Wazuh.
Team wants to keep a small, stable host IDS with minimal components	OSSEC	OSSEC covers log analysis, file integrity checking, rootkit detection and active response under GPL-2.0. It fits when you already have a log pipeline and do not need a web console, indexer or packaged dashboards.
Existing SIEM only needs host telemetry	OSSEC or Wazuh agents, with the existing SIEM as the analysis layer	Choose based on the agent you can deploy and maintain. Confirm that your SIEM supports the log format and the agent's supported platforms, including any AIX or HP-UX hosts, before standardizing.
Estate already mixes OSSEC and Wazuh agents	Wazuh server	Because OSSEC agents are compatible with the Wazuh server, both can report to one manager. Keep the Wazuh server as the single point for rules and upgrades, and inventory agent versions before cutover.
Regulated environment needing evidence of alert coverage	Wazuh	Mapped rules and central storage make it easier to show detection coverage to an assessor. Confirm which control mappings your auditor accepts, since DeployOpen prepares evidence but does not issue assessments.
Air-gapped or tightly controlled host estate with limited staff	OSSEC, if staffing allows it	Fewer components usually means less to run, but you still own rule tuning and log storage. Ask any partner to quote the operating effort for each option against your own staffing and network constraints.

How Wazuh's four components change operations compared with OSSEC

OSSEC is a two-part model: a central server and the agents that report to it. Wazuh keeps that agent and server model but adds an indexer, a dashboard and a larger ruleset, so the operational picture changes in ways that affect sizing, upgrades and who is on call.

The server and agent model

Wazuh's server and agents do the job OSSEC's server and agents do: collecting logs, checking file integrity, monitoring policy and running active response. Agents report to the server, and the server runs the analysis. An existing OSSEC estate maps onto this model directly, which is why mixed fleets are possible. Check which agent versions your hosts run, because the server must support them before you change anything else.

The indexer adds a search backend

The Wazuh indexer is a new stateful service that stores and searches alert data. It is an open source fork of OpenSearch, so you now run a search cluster that OSSEC never required. Plan storage and memory for it separately from the server, and confirm with your team who owns cluster health, shard management and snapshots. Without a fixed owner, this component tends to fail quietly.

The dashboard replaces file-based review

OSSEC reviewed alerts through command-line tools and log files. Wazuh's dashboard gives a web interface over indexed alerts, which changes who can review them and how access is granted. Decide whether analysts reach the dashboard through your existing identity controls, and confirm which authentication options your Wazuh version supports before exposing it to a wider group.

Upgrades now cover four moving parts

An OSSEC upgrade mostly means the server and the agents. A Wazuh upgrade must keep the indexer, server, dashboard and agents in a compatible sequence, and the release notes define the supported combinations. Ask for a written upgrade order, a rollback path for the indexer, and a test environment that mirrors the agent mix on your production hosts.

Agent coverage beyond Linux and Windows

Wazuh agents are available for Linux, Windows, macOS, Solaris, AIX and HP-UX. If your estate includes AIX or HP-UX hosts, confirm the agent version and the features available on those platforms, since OSSEC coverage on those systems also needs checking. Patching these agents is a separate task from patching the server, so include them in your change calendar.

Ruleset patching and ownership

Wazuh ships over 3,000 built-in rules and decoders and maps alerts to MITRE ATT&CK, which reduces custom rule work compared with an OSSEC estate built on local rules. The trade-off is that rule updates now arrive as a maintained body of content you must test. Assign an owner to review rule changes before they reach production, and track local rule overrides so upgrades do not silently change alert volume.

Can OSSEC agents report to a Wazuh server?

Yes, within limits you must verify. The Wazuh team forked OSSEC in 2015, and the Wazuh documentation states that OSSEC agents are compatible with the Wazuh server, so a mixed estate can report to one Wazuh server during a phased move. You can point a subset of hosts at the new server while the rest keep their existing OSSEC agents. Compatibility is the starting assumption for the pilot, not its conclusion. Check the Wazuh release notes for the server version you plan to run, since 4.14.9 is the current 4.x release, and confirm which OSSEC agent versions in your estate are supported with it. OSSEC 4.4.0 is the current OSSEC release, but older agents in your estate may differ.

Build the pilot from hosts that represent your estate, not from the easiest servers. Test agent enrollment, key handling and check-ins for each OSSEC agent version you run, and record any agent that fails to report. For rule coverage, export your custom OSSEC rules and decoders, then compare the alerts they generate against the Wazuh ruleset, which ships over 3,000 built-in rules and decoders. Note which detections fire, which duplicate, and which go silent. For active response, run each response script on a non-production host and confirm the trigger conditions, the timeout behavior and where the action executes. Use a simple illustrative test: if a brute-force rule triggers a block on an OSSEC host, the same event on a migrated host should produce the same block and a matching alert.

Confirm every step against the migration documentation for your target version. The Wazuh migration guide in the sources is versioned at 3.13, so locate the guide that matches your server release before you rely on its agent or configuration details. Set cutover criteria in writing before the pilot begins, and keep the OSSEC server running until those criteria pass, so you have a documented rollback. Both Wazuh server and agents are GPL-2.0 licensed, so the main cost is staff time for testing, rule review and cutover. If you want outside help, DeployOpen plans and implements migrations under a fixed scope agreed in writing before work starts.

Capability comparison: detection, dashboards, vulnerability and ATT&CK mapping

This table compares the detection functions OSSEC provides with what Wazuh adds on top of the same host-based foundation. Read the OSSEC column as the baseline and the Wazuh column as the extensions, then confirm details such as vulnerability detection and compliance modules against the documentation for the exact version you plan to run.

Capability	OSSEC	Wazuh
Log analysis	Performs log analysis as a core host-based function	Performs log analysis with decoders and rules shipped in the ruleset
File integrity checking	Included as a core host-based function	Included, inherited from the OSSEC-derived agent and server design
Policy monitoring	Included as a core host-based function	Included, with the ruleset adding built-in policy content (confirm coverage for your platforms)
Rootkit detection	Included as a core host-based function	Included, inherited from the OSSEC-derived agent and server design
Real-time alerting and active response	Included as a core host-based function	Included, with alerts flowing into the central indexer and dashboard
Central dashboard and indexer	Not part of the OSSEC project scope	Includes a central dashboard and an indexer, which Wazuh documents as an OpenSearch fork
Built-in rules and decoders	Rule set maintained as part of the OSSEC project	Over 3,000 built-in rules and decoders in the Wazuh ruleset
MITRE ATT&CK mapping	Not a documented OSSEC feature in the supplied sources	Maps alerts to MITRE ATT&CK per the Wazuh ruleset documentation
Vulnerability detection and compliance modules	Not in scope for the OSSEC project	Confirm coverage and module details against Wazuh documentation for your version

What the licenses allow and what is paid for

The Wazuh server and agent are licensed under GPL-2.0 with an OpenSSL linking exception, according to the LICENSE file in the Wazuh repository. The GPL is a copyleft license, which means that if you distribute a modified version of these components to anyone outside your organization, you generally must release the corresponding source under the same terms. Running the software internally, without distributing it, does not by itself trigger that distribution obligation, but your legal team should confirm how your use maps to the license text.

Internal use: Running unmodified or modified server and agent code inside your own environment is different from distributing binaries to third parties, such as a managed service provider or a subsidiary outside the group.
Modified agents: If you change agent code and push those builds to endpoints you own, confirm with counsel whether the endpoints count as distribution in your context.
Packaging: Custom packages, internal forks and vendor-supplied builds each carry their own license questions.
Linking exception: The OpenSSL linking exception is a specific carve-out in the license file, so read its wording rather than summarizing it from memory.
Check: Ask Wazuh and your counsel which obligations apply to your planned build and distribution model before you change any server or agent code.

Which release lines to plan around

Start by pinning each component to a release line that still receives maintenance. OSSEC's current release is OSSEC 4.4.0, published on October 5, 2026, and it follows 4.0.0, published on February 1, 2026. Wazuh's current 4.x release is Wazuh 4.14.9, released on October 14, 2026. Record the exact version of every server and agent in your inventory, because an estate that mixes OSSEC and Wazuh agents will carry two release cadences. Confirm with each project's release notes which lines are still supported before you commit a production build to them.

A Wazuh 5.0.0 release candidate was published on GitHub on October 5, 2026. Treat it as a lab artifact only. Deploy it into a test environment that mirrors your agent mix, your rule customizations and your indexer sizing, then confirm that alerts, decoders and active response behave as they did on 4.14.9. Do not place a release candidate on production servers or agents, and do not assume that a 5.0.0 final release will keep the same configuration keys or agent behavior.

Before upgrading any production agent, read the Wazuh release notes for the target version and check for changes to agent compatibility, decoders and rule IDs that your local rules depend on. Upgrade the server first in a staged window, confirm agents still report, then upgrade agents in rings. Keep the previous package and configuration available for rollback. Ask your implementation partner to document the exact versions and rollback steps in the change record, so the next upgrade starts from a known state.

Migrating an existing OSSEC estate to Wazuh step by step

This sequence moves an OSSEC deployment to Wazuh in controlled stages, so each agent group, rule set and response script is verified before the old server is retired and rollback stays available until parity is proven.

Inventory rules, decoders and active response scripts
Your security engineer exports the OSSEC configuration from the manager, including ossec.conf, local rules, local decoders, the agent list, and every custom active response script. Record which agents run which policies and which alerts drive automated actions. The step is complete when you have a versioned inventory that lists every custom artifact and the host or group it applies to. Treat this inventory as the baseline for every later parity check.
Classify what transfers and what needs rebuilding
Working from the inventory, the security engineer sorts each item into three groups: agent-side behavior that OSSEC agents already share with Wazuh, server-side rules and decoders that need review against Wazuh's own rule and decoder structure, and active response scripts that depend on the old server's paths or interfaces. OSSEC agents report to the Wazuh server, so agent-side collection is the easiest part to keep. Rules, decoders and scripts usually need testing and adaptation. Confirm the exact compatibility details against the Wazuh migration documentation for your target 4.x release. The step closes with a signed-off list of items marked keep, rework or rebuild, with an owner for each.
Stand up the Wazuh indexer, server and dashboard
The platform team deploys the Wazuh indexer, server and dashboard in a non-production environment that matches your network zones, storage plan and authentication model. The Wazuh stack includes the indexer, server, dashboard and agents, so you need all of them running before any agent is moved. Apply your hardening baseline, configure backups for the indexer, and confirm that the dashboard reaches the server API. The step is complete when a test agent enrolls, reports events, and appears in the dashboard with its alerts searchable.
Migrate custom rules and decoders into Wazuh
The security engineer ports each item marked for rework into the Wazuh server's custom rule and decoder locations, one group at a time, and tests each against captured log samples from the OSSEC estate. Keep the original OSSEC files untouched so you can compare outputs. Rule IDs and levels may differ from OSSEC, so record every mapping. The step closes when each migrated rule fires on its reference sample and produces the same severity and alert text as the OSSEC rule it replaces, or when a documented difference has been approved.
Rebuild active response scripts and test them safely
Active response scripts are the most environment-specific part of the estate, so rebuild them against the Wazuh active response model and test each one in an isolated lab first. Confirm which commands run on which endpoints, what permissions they need, and how they are triggered. Disable any automated blocking in production until a human has reviewed the test output. The step is complete when each script has been executed in the lab, its effects are logged, and a documented manual override exists for every automated action.
Onboard a pilot agent group and validate alert parity
Enroll a small pilot group of agents with the Wazuh server while they keep reporting to the OSSEC server if your design allows dual reporting, or move a single non-critical group if it does not. Run the same synthetic events through both systems and compare the alerts, severities and file integrity or rootkit findings. Keep a parity log that lists every difference and its disposition. The step is complete when the pilot group produces alerts that your SOC accepts as equivalent to OSSEC for the agreed test cases, and every gap has a fix or an approved exception.
Cut over agents in waves with a rollback path
Move the remaining agents in waves by host group, starting with lower-risk systems and ending with high-value assets. Before each wave, record the agent configuration you are replacing and keep the OSSEC manager running and reachable until the last wave passes review. Watch enrollment, event volume and alert quality after each wave, and pause if coverage drops. Rollback means re-pointing the wave's agents to the OSSEC manager, which is only possible while that manager still holds its configuration and keys. The step is complete when every agent reports to Wazuh and the OSSEC server has seen no new traffic for an agreed observation period.
Retire the OSSEC server with evidence
Once every wave is verified, the team archives the OSSEC server's configuration, rules, decoders, logs and inventory in a read-only location that your retention policy requires. Remove scheduled jobs, network access and service accounts that only the old server used, and update the asset register and runbooks. Confirm with your compliance lead which records must be kept and for how long, because that requirement comes from your own policy, not from either product. The step closes with a retirement record that links the inventory, parity log and cutover records, so an auditor or incident responder can trace each alert back to its origin.

What drives the running cost of each platform

Wazuh and OSSEC carry different running costs because they run different stacks. The cards below cover where those costs sit, who pays for them, and which ones recur, so a written quote can be compared line by line.

Infrastructure for the indexer and dashboard

Wazuh runs four central components: the indexer, server, dashboard and agents. The indexer and dashboard add compute and memory that an OSSEC server does not need, because OSSEC has no search index or web front end of its own. Ask for the node count, CPU and memory per node, and whether the quote covers high availability. These are largely recurring costs in cloud or data center capacity, and they rise with the number of monitored endpoints.

Storage growth from alert retention

Wazuh stores alerts and archived events in the indexer, so disk use grows with event volume and the retention period you set. OSSEC writes its alerts to local files, which makes its storage simpler but leaves search and long retention to other tools. Ask the quote to state the assumed events per second, the retention period, and the disk tier. Storage is recurring, and it is often the line that grows fastest after go-live.

Staff skills for the wider stack

Running Wazuh well means someone understands the indexer, the dashboard, agent enrollment and rule tuning, not just the host agent. OSSEC needs fewer moving parts, but the team still needs to write and maintain its rules and decoders. Staff time is usually the largest recurring cost, whether it is an internal salary or an external retainer. Ask which skills the implementation handover covers and whether training is included in the fixed scope.

Upgrade and testing effort

Wazuh has a 4.x release line and a 5.0.0 release candidate, so the upgrade path and the timing of the move to 5.0 belong in the plan. Each upgrade touches four components, and each needs regression testing of rules, dashboards and agent versions. OSSEC 4.4.0 is the current OSSEC release, so its upgrades are fewer but still need testing against your agents. Ask who tests, in which environment, and how many upgrade cycles the quote includes.

Support and who is paid for what

The Wazuh and OSSEC projects are open source and carry no license fee, so the recurring spend is on people, infrastructure and any support contract you choose. Support from the project community is not the same as a service level agreement. DeployOpen runs fixed-scope implementations and retainers for ongoing support and upgrades, and the quote should separate one-time setup from recurring retainer fees. Ask for response expectations in writing and who holds the on-call duty.

Migration effort for an existing OSSEC estate

Wazuh documents that OSSEC agents are compatible with the Wazuh server, so a mixed estate can report to one server during a phased move. This keeps the migration cost mostly one-time: server build, agent rollout waves, rule review and dashboard setup. Ask the quote to list each agent group, the rule set to be reviewed, and the rollback plan. The effort is driven by how heavily your OSSEC rules were customized.

Where Wazuh and OSSEC implementation projects usually run long

The slow points in a Wazuh or OSSEC project are rarely the installation itself. They sit in custom rule tuning, agent deployment across mixed hosts, index sizing and retention, integration with existing ticketing or SIEM tools, and role-based access. Plan for these first. Custom rules written in local_rules.xml must be tested against real log volume so that the built-in ruleset of more than 3,000 rules and decoders does not flood analysts with noise. Agent rollout is slower where estates mix Linux, Windows, macOS, Solaris, AIX and HP-UX, because each platform needs its own package path, group assignment and change approval. Confirm with your own asset inventory how many hosts run each operating system before you estimate effort.

Retention and indexing decide the long-term cost of the platform. In Wazuh, the indexer stores alerts and archives, so the retention period, index lifecycle policy and disk sizing should be settled in writing before the first production agent reports. Ticketing and SIEM integration is the other common delay: alert formats, severity mapping and forwarding paths need owners on both sides. For role-based access, decide early who may change rules, who may view agent groups and who may acknowledge alerts, since these roles are configured in the Wazuh dashboard and changing them late forces rework.

A fixed-scope written agreement from DeployOpen states the systems in scope, the agent count and operating systems, the custom rules to be written and tested, the integrations to be delivered, the access model and the deliverables that close the project. Anything outside that list is a change request, which is one reason this scope needs to be precise. To make the scope workable, the client should supply an asset list with owners, a named owner for each integration target, approved change windows for agent rollout and a decision on retention. Ask any implementation partner to show how each of these inputs maps to a line in the written scope.

Questions buyers ask before choosing or migrating

Is OSSEC still maintained in 2026?

Yes, the project still publishes releases. OSSEC 4.4.0 was published on October 5, 2026, following 4.0.0 on February 1, 2026, according to the project's GitHub releases page. A release date alone does not show how long a line will be supported, so review the release history, open issues and patch activity for the OS versions you run before you commit. OSSEC is a host intrusion detection system, so it does not include an indexer or dashboard. If your team needs search, dashboards and a central place for alerts, factor in the work to build those yourself or confirm what the project provides in your environment. Wazuh 4.14.9 is the current 4.x release, and a 5.0.0 release candidate was published on October 5, 2026.

Can OSSEC agents keep reporting during a Wazuh migration?

Yes. OSSEC agents are compatible with the Wazuh server, so mixed OSSEC and Wazuh agents can report to one Wazuh server during cutover, according to Wazuh's migration documentation. The practical questions are agent version, operating system coverage and configuration. Agent settings written for OSSEC need to be reviewed against Wazuh's configuration model, and custom rules and decoders need to be checked against the Wazuh ruleset. Test on a small, non-production group first, confirm the agent version you run is supported with the Wazuh server version you deploy, and keep the OSSEC agents running until each host has been validated. Plan for a parallel period in which alerts from both paths are compared, so gaps are found before the old path is removed.

How much effort does a Wazuh deployment need to run?

Effort depends on four components working together: the Wazuh indexer, the server, the dashboard and the agents. The indexer is an open source fork of OpenSearch, so teams with OpenSearch operations experience will recognize its storage and index management tasks. The Wazuh ruleset ships over 3,000 built-in rules and decoders and maps alerts to MITRE ATT&CK, which reduces the work of writing detections from scratch. Ongoing effort still comes from sizing the indexer for your event volume, setting retention, tuning rules to remove noise, maintaining agent groups across operating systems, applying upgrades and keeping integrations with ticketing and notification tools working. Ask the vendor or your integrator to size the deployment from your host count, event rate and retention requirement before you select hardware.

Can our team migrate an OSSEC estate without outside help?

It depends on how much your estate has been customized and how much your team has done this before. A small estate with one OSSEC server, a documented configuration and standard rules is usually a reasonable first project for an in-house team that already runs Linux services and has a lab to test in. The work becomes harder when the estate has custom rules and decoders, active response scripts, many operating system versions, integrations with other tools or compliance evidence that must be preserved. Consider whether your team can own the indexer, server, dashboard and agent lifecycle after cutover, since migration is only the first step. If the in-house skills, lab capacity or change windows are short, an outside implementation partner can take on part of the work under a written scope.

What drives the cost of outside help for a Wazuh migration?

The cost comes from the people doing the work and the scope they are asked to cover. Typical components include inventory and discovery of the existing OSSEC estate, architecture and sizing of the Wazuh indexer, server and dashboard, deployment and hardening, agent rollout, porting custom rules, testing, documentation, handover and any ongoing support. DeployOpen plans and implements self-hosted platforms in the client's own infrastructure. Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts, and DeployOpen does not publish a price list, so a quote follows from that written scope. One-time work covers the migration itself. Recurring costs cover upgrades, support and continuous testing if you choose a retainer. Ask any provider for itemized deliverables, the environments in scope and the assumptions behind the quote.

What does a migration need from our side?

Most delays come from missing inputs, so gather these before the work is scoped:

Access to the OSSEC servers, agent configurations and any scripts that run through active response
A current inventory of hosts, operating system versions and agent versions
Copies of custom rules, decoders and alert handling, plus the compliance controls they support
Network paths between agents and the new server, and firewall change approvals
Retention, data residency and access requirements for stored alerts
Named owners who approve changes, test results and cutover
Change windows, backup and rollback plans, and agreed acceptance criteria for each stage

DeployOpen's implementation work happens inside your own cloud accounts, data centers or air-gapped networks, so confirm where the environments sit and who can grant access to them.

How long does an OSSEC to Wazuh migration take?

No single duration applies to every estate, so the schedule should follow the drivers that change it. These include the number of hosts and operating systems, the number and complexity of custom rules, the size of the indexer deployment, the number of integrations, how many change approvals are required and how long you want the old and new paths to run side by side. Teams that keep OSSEC and Wazuh agents reporting in parallel usually need time to compare alert output before retiring the old server, and that comparison period is often the longest step. Ask for a timeline that is written into the scope, with milestones for discovery, lab validation, pilot, staged rollout and decommissioning, and confirm which of those milestones depend on your own change calendar.

Should we deploy Wazuh 5.0 or stay on the 4.x release line?

For most production plans, begin with the stable 4.x line and evaluate 5.0 in a lab. Wazuh 4.14.9 is the current 4.x release, published on October 14, 2026, according to the Wazuh release notes, and a Wazuh 5.0.0 release candidate was published on GitHub on October 5, 2026. Release candidates are intended for testing, so check the release notes for changes to agents, the indexer, the dashboard and rule formats before you plan the migration around them. Confirm which agent versions support the server version you select, and confirm that your custom rules, integrations and compliance mappings work on the target release. Record the decision and the reason for it, so the upgrade path is clear when 5.0 reaches a stable release.

How DeployOpen works on this

DeployOpen helps teams decide between Wazuh and OSSEC, then plans, implements or migrates the option the written scope supports. The work runs inside your own cloud accounts, data centers or air-gapped networks, and the scope is agreed in writing before any work starts.

How we scope

Inventory every OSSEC server, agent and rule customization before choosing a target architecture.
Record which agent platforms, log sources and compliance evidence the monitoring must cover.
Agree in writing whether the work is a fresh Wazuh deployment, an OSSEC upgrade or a staged migration.

How we build

Stand up the Wazuh indexer, server and dashboard in your environment, with the chosen agent groups.
Run OSSEC and Wazuh agents side by side in a test group to confirm reporting before cutover.
Test alert routing, active response and ATT&CK-mapped detections against scenarios you approve.

How we hand over

Document the architecture, configuration files, rule changes and agent enrollment steps for your team.
Provide a cutover runbook with rollback steps for each agent group in the estate.
Walk your operators and security engineers through alert triage and daily health checks before sign-off.

How we support

Offer ongoing support, upgrades and continuous testing as a retainer after handover.
Plan Wazuh 4.x patch and upgrade windows against your change control process.
Review new release notes and agent compatibility with your team before each upgrade is scheduled.

Wazuh vs OSSEC