This is the security-tooling version of a story this site sees a lot: Broadcom acquired Symantec’s enterprise business, and licensing minimums, bundling, and renewals went up. Teams looking for a self-hosted, no-license-fee alternative often land on Wazuh, an open-source security platform that combines endpoint detection, file integrity monitoring, log analysis, vulnerability detection, and security configuration assessment with a SIEM-style backend. The important honesty up front: Wazuh is not a drop-in AV replacement. It is a detection, visibility, and response platform, so the migration is partly a re-architecture of how you do endpoint security, not just a product swap.
Where Wazuh covers you, and where it doesn’t
- What it replaces well: endpoint detection and response signals, file integrity monitoring (FIM), log collection and correlation, vulnerability detection, security configuration assessment (CIS-style), and active responses. This covers a large part of what teams use SES for day to day.
- What it does not natively do: signature-based real-time antivirus quarantine the way SEP does. Many teams pair Wazuh with the OS-native defenses (Microsoft Defender on Windows, ClamAV, or an EDR engine) and use Wazuh as the detection, correlation, and response brain. Decide this design before you start, or you will leave a prevention gap.
From SEP policies to Wazuh rulesets
Symantec policies do not export into Wazuh, you reimplement intent:
- SEP protection/firewall/IPS policies become Wazuh rules and decoders plus active responses, and OS-level controls.
- Application/device control maps to SCA policies and OS hardening baselines.
- Reporting and alerts become Wazuh dashboards and alerting rules feeding your ticketing/SIEM.
Start from Wazuh’s out-of-the-box rulesets and CIS benchmarks, then tune to your environment rather than trying to recreate every SEP setting one-to-one.
A useful way to sequence this is to work policy category by policy category rather than host by host. Take your SES protection policies first and decide which parts are detection (reimplement as Wazuh rules) and which parts are prevention (assign to the OS-native layer). Then do firewall and IPS intent, then application and device control against SCA and hardening baselines, then reporting and alerting. Working by category keeps you from porting the same setting several times and makes it obvious where a control has no Wazuh equivalent and must live in the prevention layer instead.
Roll out in parallel, never blind
- Stand up the manager and indexer (Wazuh manager plus the indexer/dashboard), sized for your event volume, this is real capacity planning.
- Deploy agents in waves alongside the existing SEP agents, a representative pilot group first.
- Tune rules and FIM scope on the pilot to cut noise before you scale, alert fatigue kills a rollout faster than anything.
- Validate coverage (detections firing, FIM and SCA reporting, vulnerability data flowing), then expand wave by wave.
- Decommission SEP only after Wazuh plus your chosen prevention layer cover every endpoint and the SOC trusts the new signals.
Proving coverage wave by wave before SEP goes
The whole point of running both agents in parallel is that you can prove Wazuh’s coverage against a live baseline before you trust it. Set an explicit acceptance bar for each wave rather than eyeballing the dashboard. Confirm that the detections you rebuilt actually fire on safe tests such as EICAR or atomic red-team style checks, that FIM is reporting changes on the paths you designated as sensitive, that SCA is running your CIS baseline and surfacing drift, and that vulnerability data is flowing. Verify active responses trigger the way you intend, ideally in a controlled test, because a misconfigured auto-response can disrupt endpoints.
Just as important, confirm the prevention layer is healthy on every host in the wave, since that is the piece Wazuh does not provide. Only when both halves check out, detection trusted in Wazuh and prevention confirmed on the OS-native engine, do you retire SEP on that wave. Decommissioning wave by wave, never estate-wide at once, is what guarantees you never drop below the coverage SEP was giving you.
The details that bite
- Prevention gap. If you remove SEP’s AV without a replacement prevention layer, you have downgraded protection, not migrated it. Pair Wazuh with native/OS defenses deliberately.
- Tuning is the project. Default rules are a starting point; untuned FIM and SCA generate noise. Budget time for tuning, not just deployment.
- Capacity and retention. Event volume drives indexer sizing and storage retention, plan it like a SIEM, because it is one.
- Response workflows. Active responses are powerful but need testing, a misconfigured auto-response can disrupt endpoints.
What to do next
Symantec Endpoint Security to Wazuh removes Broadcom licensing in exchange for building and tuning an open security platform, and for pairing it with a prevention layer Wazuh does not provide. Decide the prevention design first, reimplement policy intent as Wazuh rulesets and SCA baselines, and roll agents out in parallel with tuning before scale. Treat indexer sizing and rule tuning as the real work, not agent deployment. Model the removed per-endpoint subscription against the infrastructure and SOC time to run Wazuh in the calculator above.