From Trend Micro to Wazuh

Trend Micro Apex One bundles prevention, detection, and management behind per-seat licensing that climbs fast across a fleet. Wazuh is the open-source platform teams move to, but read this before you plan anything: Wazuh is a detection, visibility, and XDR-style platform, not a drop-in signature antivirus. It does EDR, file integrity monitoring, log analysis, vulnerability detection, and security configuration assessment. It does not do real-time signature-based prevention that quarantines a malicious file the instant it lands. If you swap Apex One for Wazuh alone, you have traded a prevention product for a detection product and left a gap.

Architect the prevention layer first

Wazuh replaces the detection and response half of Apex One. You still need a prevention engine underneath:

• Windows: Microsoft Defender Antivirus. It is already on every modern Windows host, free, and a competent signature and behavioral engine. Wazuh reads Defender’s events and can trigger active responses.
• Linux: ClamAV (or the distro’s controls) for on-demand scanning, hardened with the host firewall and SELinux/AppArmor.

So the real architecture is Defender/ClamAV for prevention + Wazuh for detection, visibility, and response. Plan and message it that way internally so nobody assumes “Wazuh = our new AV.”

What each Apex One policy really enforces

Translate what your Apex One policies actually enforce, not the product features one to one:

• Behavior monitoring / IOC rules → Wazuh rules and decoders in the ruleset, firing alerts at a severity level.
• Compliance and lockdown policies → Security Configuration Assessment (SCA), CIS-benchmark style checks run by the agent.
• Device-control and integrity expectations → File Integrity Monitoring (FIM) on the directories that matter.
• Patch posture → vulnerability detection, which correlates installed packages against CVE feeds.
• Real-time block actions → Wazuh active response scripts (firewall-drop, disable account) plus the OS prevention engine doing the actual blocking.

A FIM stanza in ossec.conf to watch a sensitive path with real-time and hashing:

<syscheck>
  <directories check_all="yes" realtime="yes">C:\Windows\System32\drivers\etc</directories>
  <frequency>43200</frequency>
</syscheck>

Indexer capacity planning

This is where Wazuh rollouts fall over. Every agent ships events into the Wazuh indexer (an OpenSearch fork), and EDR plus FIM plus log collection is a lot of data. Size it before you scale:

• Budget roughly 0.5 to 1 GB of indexed data per agent per day as a starting estimate, then measure your real volume in the pilot.
• Plan hot/warm tiers and index lifecycle management so 90-day retention does not fill the disk.
• For more than a few hundred agents, expect a multi-node indexer cluster, not the single-node all-in-one.

Undersize the indexer and the whole platform stutters; this is the number one operational surprise.

Parallel rollout and tuning

Do not flip the fleet. Trend Micro and the Wazuh agent coexist on the same host, so:

1. Stand up the manager and indexer, sized from the estimate above.
2. Deploy the Wazuh agent to a pilot group while Apex One keeps protecting them.
3. Tune before you scale. The default ruleset is noisy; spend real time suppressing false positives, writing custom rules, and setting alert levels on the pilot data.
4. Roll out in waves, validating that Defender/ClamAV is healthy on each host as you go.
5. Only remove Apex One once prevention is confirmed on the OS engine and detection is trusted in Wazuh.

Using the overlap to confirm coverage

Running Trend Micro and Wazuh in parallel is only worth the effort if you use the overlap to prove coverage before you cut over. Set a concrete acceptance bar per wave instead of trusting the dashboard by feel. Confirm the rules you rebuilt actually fire against safe tests such as EICAR or atomic red-team style checks, that FIM is reporting on the sensitive paths you scoped, that SCA is running your benchmark and flagging drift, and that vulnerability data is flowing from the agents. Test active responses in a controlled way before you rely on them, because a firewall-drop or account-disable script that misfires can take a host offline.

Then validate the half Wazuh does not own: confirm Defender or ClamAV is installed, updated, and actively protecting every host in the wave. That prevention check is the gate. Only when detection is trusted in Wazuh and prevention is confirmed on the OS engine do you remove Apex One from that wave, and you do it wave by wave so the fleet never drops below the protection Apex One was providing.

Where Trend Micro still wins

Be honest before committing:

• Turnkey prevention. Apex One blocks known threats out of the box with a maintained signature and reputation feed. Recreating that posture with Defender/ClamAV plus Wazuh tuning is more moving parts.
• Managed XDR and threat intel. Trend’s MDR service and curated intelligence mean a SOC watches for you. Wazuh hands you the console and the alerts; the analyst is you.
• Single-vendor support. One throat to choke for prevention and detection together matters for lean or regulated teams. With Wazuh you integrate and operate the stack yourself.

If you have no detection engineering capacity, an Apex One renewal may well be cheaper than the staffing Wazuh implies.

The realistic takeaway

Trend Micro to Wazuh removes per-seat licensing but only if you understand you are replacing the detection half and must keep a prevention engine (Defender on Windows, ClamAV on Linux) underneath. The work is mapping policies to rules, SCA, and FIM, sizing the indexer honestly, and tuning on a pilot before scale. Run both agents in parallel until prevention and detection are both proven. Model the per-seat saving in the calculator above, then subtract the indexer infrastructure and the detection-engineering time that turnkey XDR was quietly covering for you.