Wazuh 5.0 is almost here!

Wazuh 5.0 is not an ordinary update with a handful of new features. It fundamentally changes how the platform receives events, normalizes and stores them, evaluates rules, and presents results to analysts. The manager and indexer take on different responsibilities, Filebeat leaves the default pipeline, and rules and decoders gain a new lifecycle. Detection moves closer to the indexed data. Wazuh Common Schema, IOC and GeoIP enrichment, Case Management, redesigned Active Response, and an integrated AI Assistant complete the picture.

The most important operational change is this: Wazuh 4.x central components cannot be upgraded to 5.x in place. The transition requires a new environment, migration or recreation of supported data and configuration, and a controlled move of agents. For many organizations, Wazuh 5.0 will be both a technology upgrade and a migration project.

Wazuh 5.0 is approaching release. We examined the source code and tested version 5.0.0 Beta 5. The examples show this pre-release build; the final release may introduce further changes. This is not a recommendation to deploy the beta in production.

We can help you plan deployment and migration, from architecture to verification of custom rules. We are also preparing practical demonstrations for our Wazuh webinars.

We validated the examples on three isolated Ubuntu 24.04 VMs: Wazuh 4.14.7, Wazuh 5.0.0 Beta 5, and one migrated agent. No Docker was used. The pilot preserved agent ID 001 through upgrade, fully verified HTTPS communication, rollback to 4.x, and return to 5.x including a reboot. A replay of 35 synthetic SSH messages produced 30 failed-authentication and 5 successful-authentication findings. The agent synchronized 279 SCA results and an initial 3,576 FIM records; snapshot restoration recovered 639 of 639 historical documents. These are controlled test scenarios, not production incidents or a throughput benchmark.

Validation boundary: the complete package-inventory and Vulnerability Detection flow was not proven; the initial package-state count was zero and Syscollector VD reported a synchronization warning. The feature overview also draws on documentation and source inspection, not exhaustive runtime testing of every capability.

Why Wazuh 5.0 is a new generation

In a simplified Wazuh 4.x deployment, the manager receives agent data, decodes it, evaluates rules, and writes alerts. Filebeat reads the alert file and forwards documents to the indexer for the dashboard. This concentrates much of the analysis on the manager and ties detection content to its filesystem.

Wazuh 5.0 divides the work into two analytical layers:

• The normalization engine in the manager receives raw events, selects integrations and decoders, parses the input, maps it to Wazuh Common Schema, and can add GeoIP, ASN, and IOC context.
• The detection engine in the indexer evaluates normalized documents using Sigma-compatible rules and detectors. Matches produce findings, the successor to 4.x alerts in the new architecture.

log source / agent
        ↓
Wazuh manager: receive → decode → normalize → enrich
        ↓  indexer-connector
Wazuh indexer: store event → detector → Sigma rule
        ↓
finding → dashboard → analyst / notification / Active Response

This is more than an internal refactor. It affects rule formats, index names, field names, operating metrics, retention, dashboards, and incident response. A script reading alerts.json, a dashboard using wazuh-alerts-*, or automation depending on numeric rule.level values will need review and modification.

An event is not a finding

An event records what happened. A finding records a rule match. An event may be processed by multiple active policies and match multiple detection rules, so event and finding counts need not be equal.

Analysts can search the normalized event stream separately from security findings. A finding includes the source event, rule metadata, severity, MITRE ATT&CK and compliance mappings, and optionally case metadata. A query against wazuh-events* therefore answers a different question from a query against wazuh-findings*.

Operational implications

• Collection and detection have a clearer boundary.
• Rules consume a normalized schema instead of inconsistent product-specific fields.
• Integrations, decoders, and rules become managed content with a controlled lifecycle.
• Indexer capacity affects not only searches but also detection latency.
• Migration testing must cover the entire pipeline, not just agent connectivity.

Wazuh 5.0 is not simply a package upgrade. Contact us to assess how it affects your custom decoders, rules, integrations, retention, and automation. We can prepare a dependency inventory and realistic migration plan before production changes begin.

Filebeat is replaced by the native indexer connector

The default data path no longer relies on a separate Filebeat process reading JSON alerts. Wazuh 5.0 sends normalized events from the manager directly to the appropriate indexer data streams through indexer-connector.

This removes the shipper layer, its filebeat.yml, modules, and file-reading queue. According to the 5.x documentation, the manager no longer stores endpoint alerts locally in the same way. Consequently, old troubleshooting procedures centered on alerts.json and the Filebeat registry are insufficient.

Check the following instead:

• Reachability of the indexer nodes from the manager.
• TLS certificates and the connector account's permissions.
• Connector logs, including the calling module's context.
• Manager queues and watermarks.
• Indexing errors, mapping conflicts, and data-stream health.
• Communication and normalization metrics in the dashboard.

The release notes introduce a restricted wazuh-server account for the manager-to-indexer connection. However, the Beta 5 engine source still contains an internal wazuh-manager fallback. Do not infer the effective account from one default: check the username in the manager keystore and its actual indexer roles after installation.

The audited source defaults include an event queue of 131,072 slots and 32 MB, a 64 MB indexer-connector queue, 8 MB bulk batches, and a 20-second flush interval. The orchestrator measures both item and byte occupancy, counts dropped input, and warns after ten minutes of sustained contention above 90%. These are source fallbacks, not universal sizing recommendations; package configuration may override them. Monitor queue utilization, dropped events, and one-, five-, and thirty-minute EPS.

What happens to custom outputs?

Removing Filebeat does not prohibit integration with other analytics platforms. It does mean that custom Filebeat pipelines, Logstash configurations, copies of alerts.json, and external archives need an explicitly designed replacement.

Separate three requirements:

1. New Wazuh 5.0 operational data written to the new data streams.
2. Historical 4.x data restored from snapshots, retaining its original schema and not receiving new 5.x writes.
3. External exports to archives, data lakes, or another SIEM, with their own supported data path.

Wazuh Engine and Security Analytics

Wazuh Engine is not simply a renamed analysisd. The architecture combines normalization in the manager, content management in the indexer, and detection over normalized documents. The dashboard groups this work under Security Analytics.

The content model includes:

• Integration: related content for a product or log source.
• Decoder: recognition, parsing, and WCS field mapping.
• Rule: detection conditions in Sigma-compatible YAML.
• Detector: rule selection, target index or alias, and execution schedule.
• KVDB: key-value lists and lookups for normalization and enrichment.
• Filter: selection of events allowed into subsequent pipeline stages.
• Policy: the order and behavior of processing stages.

Content Manager: standard and custom content

The indexer's Content Manager plugin maintains rules, decoders, integrations, KVDBs, filters, and IOC content. It retrieves standard content from Wazuh CTI, provides APIs for custom content, and synchronizes changes with the manager's normalization engine.

Vendor content and an organization's custom content are separated instead of sharing an editable directory tree. This reduces the risk of vendor updates overwriting local changes and provides a workflow for testing changes before activation.

The current design periodically checks for content updates and supports manual updates. The indexer installation also includes ruleset, vulnerability, and IOC snapshots, providing initial content without requiring an immediate external connection.

What an update actually does

In the audited manager source, Content Manager synchronization defaults to 120 seconds; IOC and GeoIP checks default to 360 seconds. The manager compares the remote policy's SHA-256 hash with the deployed version and avoids reloading unchanged content.

Changed content is downloaded into a temporary namespace and validated before an atomic switch of the active route. The implementation contains rollback paths for failed imports and hot swaps. It also avoids downloading while the remote consumer is busy, preventing a snapshot of a partly updated dataset.

Content can therefore become active without restarting the whole manager, but activation is not necessarily immediate. Check the policy hash, consumer state, last successful synchronization, and active namespace—not just whether a rule is visible in the dashboard.

Four spaces: Draft, Test, Custom, and Standard

The custom-content workflow is Draft → Test → Custom. Promotion deploys and validates the content, reloads the relevant engine configuration, and updates the target space. Standard and custom policies remain separate.

This provides more control than editing XML directly on a production manager, but it does not replace Git, peer review, or regression tests. Keep YAML content versioned, associate changes with sample logs, and verify positive and negative cases before promotion.

Integrations determine ownership and routing

An integration is the top-level container for related decoders, rules, and supporting content. Each decoder belongs to one integration. The integration's category affects the destination stream:

• access-management: authentication, authorization, identity, and access.
• applications: web servers, databases, middleware, and applications.
• cloud-services: AWS, Azure, GCP, and other cloud services.
• network-activity: firewalls, proxies, DNS, and network flows.
• security: EDR, SIEM feeds, scanners, and security tools.
• system-activity: operating systems, audit, and syslog.
• other: events outside those categories.
• unclassified: events accepted by the root decoder but not classified by a specific decoder.

The category is recorded in wazuh.integration.category and affects routing, for example to wazuh-events-v5-cloud-services. An incorrect category can affect detectors, dashboards, retention, and permissions—not just a label in a list.

Decoders move from XML to YAML and WCS

Where 4.x commonly uses XML decoder files on the manager, 5.0 uses YAML assets and a small domain-specific language. Its main sections are check to select input, parse to extract structured or text data, and normalize to map the result into WCS.

An SSH example shows why changing the file extension is not enough. The standard decoder/system-auth/0 consumes parsed syslog data and sets the normalized action. This excerpt comes from its normalization section; it is not a complete importable decoder:

normalize:
  - check: $_system.auth.ssh.event == Invalid OR $_system.auth.ssh.event == Failed OR $_system.auth.ssh.event == failures OR $_system.auth.ssh.event == fatal OR $_system.auth.ssh.event == exceeded OR $_system.auth.ssh.event == Disconnecting
    map:
      - event.action: authentication-failure
      - event.category: array_append(authentication)
      - event.outcome: failure
      - event.type: array_append(info)

The test message Failed password for invalid user demo-admin from 203.0.113.10 port 51234 ssh2 produced event.action: authentication-failure, event.outcome: failure, user.name: demo-admin, and source.ip: 203.0.113.10. Standard detection rules use those normalized fields. Temporary fields such as _system.auth.ssh.event support decoding and are not part of the public output schema.

For each custom decoder, establish its accepted input, integration and category, WCS field equivalents, data retained only in event.original, required GeoIP/IOC enrichment, and dependencies in existing rules and dashboards.

Log Test covers normalization and detection

The new Log Test follows the actual processing stages. It shows which decoders accepted or rejected an input and the normalized document, then lets you inspect rule matching. Test, Custom, and Standard content can be checked, including its interaction with already active content.

Do not stop at one matching example. Maintain valid input for important format variants, unrelated input that must be rejected, missing fields and boundary values, expected normalized JSON, expected rule/severity results, and regression samples for previous false positives and false negatives.

Wazuh Common Schema: a common language for security data

WCS provides a shared data model based on ECS; the 5.0 work targets ECS 9.1.0. The same information should have the same field name and type whether it comes from Windows Event Log, a firewall, a cloud service, or a custom application.

A source address should not be srcip in one integration, source_address in another, and client.ip in a third. Mapping it consistently to source.ip makes rules, visualizations, and enrichment reusable across sources.

WCS also covers events, processes, files, users, hosts, cloud, DNS, registry data, vulnerabilities, compliance, and Wazuh metadata. event.original retains the original log for investigation.

Field changes affect queries and dashboards

Wazuh metadata moves under wazuh.*. The migration documentation lists these examples:

There is no universal replacement for rule.groups: depending on the filter’s purpose, use wazuh.integration.name or other WCS metadata. Severity also changes type, from a number in the 0–16 range to informational, low, medium, high, or critical.

Consequently, rule.level >= 10 has no direct numeric equivalent. Rewrite severity filters, alert conditions, mappings, and visualizations according to the new model.

Data streams by category and purpose

The main stream families include:

• wazuh-events-v5-{category} for normalized events.
• wazuh-findings-v5-{category} for detection findings.
• wazuh-events-raw-v5 for optional raw-event indexing.
• wazuh-active-responses for response requests.
• wazuh-metrics-* for agent, communication, and normalization telemetry.
• wazuh-states-* for inventory, SCA, FIM, vulnerabilities, and other state data.

Time-series data uses streams, templates, and Index State Management policies. The setup plugin creates these alongside initial roles and settings. ISM manages rollover and deletion. Wazuh plugin templates use the zstd codec to trade some processing overhead for storage efficiency.

Categories make differentiated retention and access control possible. Broad patterns are convenient for exploration, but expensive dashboards should query only the relevant streams.

Retention settings found in the built templates

The Beta 5 indexer-plugin artifacts contain substantially different age conditions:

Their rollover conditions include a 20 GB primary shard or 200 million documents; AI sessions also have a one-day age condition. These are scheduler-evaluated conditions, not precise timers. Actions have three retries with exponential backoff starting at one minute.

These values are not per-event TTLs. ISM finishes the current state’s actions before checking transitions. An index waiting for a volume-based rollover may remain beyond one hour; index age also differs from the age of individual documents. Effective retention depends on rollover, backing-index age, scheduler timing, and successful actions. Check the active policy and ISM Explain, and configure time-based rollover and retention to meet your needs. The short events condition deserves attention, but it does not prove that every log disappears exactly one hour later. OpenSearch’s ISM action and transition model.

The events template contains 2,299 dynamic field templates and the findings template 2,345, while mapping.total_fields.limit is 1,000. This is not a contradiction: dynamic mappings are materialized when fields first appear, rather than every template immediately becoming a mapped field. Monitor actual field counts and prevent uncontrolled field expansion in custom integrations.

The templates also configure one primary shard, auto_expand_replicas: 0-1, zstd, and a two-second refresh interval for events and findings. Treat these as installation defaults, not a production-cluster design. Derive shards, replicas, refresh, and lifecycle policies from EPS, document size, retention, and recovery objectives.

Raw and discarded events

Optional raw and discarded-event indexing helps investigate why input did not produce a finding. A pre-filter can reject input before decoding, while a post-filter runs after decoding or enrichment. Discarded events are either dropped or retained for troubleshooting according to configuration.

These options can substantially increase storage. Estimate EPS, average event size, retention, and shard impact before enabling them broadly.

Need help with capacity and retention? Contact us to build a Wazuh 5.0 design from your actual event volumes and investigation requirements.

Sigma-compatible rules replace XML detection rules

Rules use Sigma-compatible YAML with detection, logsource, Wazuh metadata, severity, and optional MITRE ATT&CK and compliance mappings. Wazuh extensions include substitution of event fields into a finding’s title.

A rule must match the decoder's actual output. This shortened standard-rule excerpt produced failed-authentication findings in the lab; the full definition also includes compliance and MITRE mappings:

id: 42532ad3-3951-57ee-a3a3-bc6a1b9e6e72
status: stable
level: low
logsource:
  product: wazuh-generic-1
  service: authentication
metadata:
  title: "Failed authentication attempt - {{user.name}} from {{source.ip}}"
detection:
  selection:
    event.action: authentication-failure
    event.category: authentication
    event.kind: event
  condition: selection

This is a single-event match, not proof of a brute-force attack. Frequency, time windows, and correlation by address or account require separate evaluation. A mistyped password alone is not a critical incident, which is consistent with this rule’s low severity.

Referenced fields must be valid WCS fields. The engine validates field references and can return a structured error instead of accepting a rule that can never match because of a typo. Supported modifiers include contains, startswith, endswith, cidr, exists, lt, lte, gt, gte, and list handling. logsource organizes content; detection defines the match.

Severity is no longer a number

The five named severity levels are easier to read but break numeric thresholds in existing automation. Do not mechanically label every old level from 10 to 12 as high. Consider the rule’s purpose, detection confidence, available context, and resulting action. Use the same mapping in dashboards, notifications, SLAs, and ticketing integrations.

Detectors separate rules from data sources

A rule describes what to find. A detector selects the target index or alias, rules, and execution schedule. Standard detectors are supplied; custom detectors can target selected streams and rule sets.

Detection is scheduled and near-real-time, not a synchronous match at log ingestion. Latency depends on the interval, indexing delay, rule count, data volume, and indexer load.

A detector uses Standard or Custom content; it cannot mix both spaces. Configurable limits govern rules per detector and user-created detectors. Group large rule libraries by source and category, and measure execution time.

Findings replace alerts

A finding includes the source document and rule metadata under wazuh.rule, such as ID, title, level, status, MITRE, and compliance. Enriched findings go to wazuh-findings-v5-{category}.

There are two stages: Security Analytics records a match, then asynchronously enriches it with the event and rule. Troubleshooting an incomplete finding therefore requires checking both the detector and the enrichment/bulk-indexing stage.

CTI, GeoIP, and IOC enrichment

Wazuh CTI becomes a distribution layer for standard detection content, vulnerability data, and indicators of compromise. Content Manager checks for updates and delivers content to the indexer and engine.

GeoIP enrichment can add location, time zone, and ASN information to source or destination addresses. IOC enrichment compares supported addresses, domains, URLs, and hashes against threat feeds and adds context under wazuh.threat.

Not every address has such context. The SSH test uses documentation IP ranges, so an address appearing in a finding is not evidence of a real GeoIP result or IOC match.

IOC enrichment adds evidence, not a final verdict. Rules can combine reputation with behavior, asset, user, and other context. Analysts should inspect the provider, first/last observation, and field that matched.

Vulnerability Detection and the indexer

Agents continue collecting operating-system, package, and hotfix inventories. In the 5.0 design, the indexer is the authoritative source of CVE data; the agent-side workflow does not directly query CTI. Synchronization distinguishes the first scan, inventory changes, and feed updates.

CVSS 4.0 and CVE 5.0 schema fields provide richer vulnerability context. Migration tests should check status, package association, severity, and behavior after inventory changes—not just the total count of vulnerabilities.

Active Response moves into the dashboard

Wazuh 4.x configures commands and responses using <command> and <active-response> in the manager configuration. In 5.0, configuration moves to Explore → Active Response. Requests enter a dedicated stream and are processed by an Alerting monitor; wazuh-execd still executes the command on the endpoint.

Configuration includes a name and description, executable and arguments, local-agent or all-agent scope, stateless or stateful behavior, a timeout for stateful actions, and the triggering rule or condition.

Do not copy the old XML blocks into the 5.x manager. Review scripts for the new finding structure and WCS field paths. The All scope remains hazardous: an overly broad rule or incorrect script can affect the entire environment.

Start with notifications, then a test group, and only later expand automatic response. Test execution, timeout, reversal, and repeated matches during an active response. A script's presence on an endpoint does not establish that the event-to-finding-to-action pipeline works.

AI Assistant in the Wazuh dashboard

The integrated Wazuh AI Assistant provides a conversational interface over vulnerabilities, findings, inventory, and agent status. Responses may include a summary, a table, and a link into Discover for checking source records.

This is not simply a general-purpose chat in an iframe. It uses tools to query Wazuh datasets, handle aggregation and time ranges, and pass queries into Discover. Conversations are stored so investigations can be continued.

Example questions include:

• Which agents are disconnected, and for how long?
• Which devices have critical vulnerabilities with known exploits?
• Which source addresses account for the most failed sign-ins?
• Which processes or listening ports exist on a selected endpoint?
• Summarize critical findings from the past 24 hours by MITRE tactic.

The source of truth remains the indexed document, timestamp, index, rule, and original event. A generated explanation helps navigation; it does not establish an incident by itself.

Providers and deployment choices

The development documentation lists Wazuh AI Assistant Brain, Anthropic, and OpenAI-compatible endpoints. In the tested Beta 5 form, we verified two choices: OpenAI-compatible and Anthropic. We did not validate Brain as a third form option, connect an external provider, or test answer quality. Depending on API and model compatibility, the latter may include OpenAI services, Gemini, Ollama, or LM Studio.

Administrators configure a provider name, endpoint, model, and API key. Keys require encrypted storage. Verify the provider, processing region, training policy, and retention before sending production data.

API compatibility does not imply equal analytical quality. The model must reliably use tools and complete multi-step queries. A local model can help keep sensitive data on your infrastructure, but accuracy and hardware requirements need testing with representative questions.

Privacy mode and field policies

Fields can be anonymized or excluded before being sent to a provider. Privacy mode can be the cluster default, and administrators can prevent users from disabling it for individual conversations.

Findings may contain usernames, hostnames, addresses, paths, command lines, cloud IDs, email addresses, and the complete event.original. Define the minimum fields needed by each scenario.

Recommended validation includes:

1. Start with enforced privacy mode.
2. Exclude original logs, secrets, tokens, command lines, and free text unless necessary.
3. Pseudonymize endpoint identities, users, and internal addresses.
4. Check repeated queries and conversation history.
5. Inspect the actual provider-bound payload in a controlled test.
6. Check both conversation retention and backing-index ISM. A documented application setting of 0 disables its time limit, but Beta 5 also has a seven-day index-age condition for deletion after rollover. Both layers affect effective retention.

What the assistant should not decide for you

Do not let an unverified generated answer close an incident, alter evidence, or authorize Active Response. An analyst should be able to reproduce the time range, filters, and results in Discover.

Before production use, create an evaluation set covering known answers, empty results, forbidden agents, sensitive fields, prompt injection inside logs, and requests for complete result sets. Assess filter correctness, completeness, RBAC, and handling of untrusted log content—not just writing quality.

Case Management: triage without a separate ticket

Wazuh 5.0 adds case metadata to findings under wazuh.case. Available fields include title and description, states such as active, acknowledged, and completed, severity, priority, TLP classification, tags, comments with author/timestamps, and the last modification identity and time.

The case enriches a finding rather than creating a separate copy of its event. Analysts can document an investigation and change its state from the finding detail. A bulk-update API has a configurable per-operation limit.

Severity, priority, and sharing are different decisions

Severity describes the security problem; priority determines how urgently the team works on it. A critical finding on an isolated lab machine may have lower operational priority than a high finding on a production identity server. TLP governs information sharing.

Set these values using asset criticality, detection confidence, impact, exploitability, scope, and whether activity is ongoing, rather than copying one label into every field.

When an external system is still needed

Built-in triage does not automatically replace a SOAR or ticketing platform with approvals, SLAs, evidence handling, CMDB relationships, and cross-system orchestration. If you already use Jira, ServiceNow, TheHive, or DFIR-IRIS, define the authoritative incident state and avoid managing two conflicting copies.

Incident Response: verify the outcome

The Incident Response application exposes response activity on monitored endpoints: the action, target, related detection, and result. This completes the operational chain:

event → finding → decision/monitor → Active Response → execution result

Sending a command does not prove it succeeded or was reversed after a timeout. Monitor success/failure rates, execution delay, frequent triggering rules, repeatedly affected endpoints, and stateful actions without a confirmed reversal.

Alerting and Notifications

Wazuh 5.0 uses Wazuh variants of the OpenSearch Alerting and Notifications plugins. A monitor queries data and evaluates conditions; a notification channel specifies the delivery destination.

Supported channel types include SMTP or Amazon SES email, Microsoft Teams, Slack, Amazon Chime, AWS SNS, and custom webhooks. The package also provides webhook types for integrations such as Jira, PagerDuty, and Shuffle. Verify exact availability and configuration in your build.

For example, a monitor can query wazuh-events-v5-system-activity every minute, filter event.action: authentication-failure, and notify on a per-source threshold. Counting events avoids multiplying failed attempts when one event produces several findings. Check the normalized action against the decoder actually in use.

Notifications and Active Response have different risks. A noisy notification is inconvenient; an incorrect account-disable or address-blocking action can cause an outage. Roll out a scenario as dashboard-only observation, then human-reviewed notifications, then scoped automatic response with a timeout and rollback.

Reporting: PDF and CSV

The old reporting implementation inside the Wazuh dashboard plugin is removed. Its replacement is based on the Wazuh fork of OpenSearch Reporting, supporting dashboard and saved-search exports, scheduled generation, and email delivery according to report type and configuration.

Previously generated PDFs and old report-branding settings do not migrate automatically. The migration documentation notes that the old custom logo/header/footer configuration is not supported in the same way.

Validate the report's tenant, time zone, time range, CSV row limit, execution-account permissions, and delivery channel. A scheduled job may produce incomplete output even when the dashboard works for an administrator.

Dashboard, navigation, and health checks

The 5.x dashboard is based on OpenSearch Dashboards 3.x and defaults to the v9 theme generation. The home page combines endpoint, finding, vulnerability, and component-health information. Navigation follows analytical tasks rather than the historic plugin layout.

Visible changes include Security Analytics; AI Assistant in the top bar and Active Response under Explore; Case Management and Incident Response; distinct patterns for events, findings, state data, and metrics; revised API/indexer/plugin/certificate/monitor health checks; Regulatory Compliance; communication and normalization statistics; and permission-controlled indexer configuration.

Compliance in one place

Regulatory Compliance brings PCI DSS, GDPR, HIPAA, NIST 800-53, and TSC into one application. The release notes also list CMMC, FedRAMP, ISO 27001, NIS2, and NIST 800-171 modules.

A compliance dashboard is not certification. It presents findings mapped to requirements. An audit still needs evidence of source coverage, correct rules, retention, access control, and remediation procedures.

Removed applications and renamed workflows

The former Rules, Decoders, CDB List, and Ruleset Test applications give way to Security Analytics and Content Manager. The old reporting plugin and parts dependent on deprecated daemons, including earlier OpenSCAP, CIS-CAT, and Osquery integrations, are removed or reorganized. Older Statistics, Cluster, and App Settings surfaces also change.

A missing menu item does not necessarily mean the whole capability is gone. Map each workflow used by your team to its new equivalent before migrating roles and internal runbooks.

Agents: local state and a new synchronization model

FIM, System Inventory, and SCA maintain working state locally on the endpoint. The architecture removes their dependency on the earlier rsync synchronization with the manager, reducing server-side work and synchronization overhead.

Central visibility remains: agents send state and changes through the new synchronization pipeline into state indices. Validate full scans, incremental updates, and recovery after connectivity loss.

Other changes include higher event-throughput and inventory-message limits, more consistent initial reads after log rotation, native Windows Event Channel XML from EvtRender(), WCS-aligned JSON for agent-start/buffer-status events, MSI-only Windows distribution, simplified rootcheck, removal of obsolete tools, and WPK packages including Linux/macOS ARM64 variants.

HTTPS communication and compression

Wazuh 5.0 introduces an HTTPS agent-manager path and enrollment endpoint, along with default zstd compression on the agent. Verify the final protocol defaults and supported migration paths when the release becomes final.

Test certificates, hostname validation, IP restrictions in client.keys, time synchronization, proxies, firewall behavior, reconnection, fixed-IP enrollment, and upgrades of existing agents. HTTPS does not manage trust by itself: define CA ownership, certificate lifetime, rotation, and expiry monitoring.

Enrollment uses a shared password

Manager installation generates an enrollment password and enables password protection by default. The secret is stored in authd.pass, synchronized to workers, and supplied through the supported agent deployment mechanism. Invalid passwords must not enroll an agent.

A shared password is still a shared secret. Restrict its distribution, store it safely, rotate it, and keep it out of public scripts, tickets, screenshots, and shell history.

A single manager is still a cluster node

Every 5.0 manager operates as a cluster node. The former standalone-versus-cluster distinction and cluster.disabled option are removed. A one-node installation is still a cluster from the API’s perspective.

This unifies code paths but changes permissions and automation. Older /manager/... calls may move to /cluster/{node_id}/... equivalents. Installation generates a random cluster key; multi-node deployments require unique node names and secure key distribution.

Security defaults and least privilege

Changes include the restricted manager-to-indexer account described in the release notes; predefined Content Manager, Security Analytics, Alerting, Notifications, and Reporting roles; wazuh-admin, wazuh-readonly, and wazuh-demo API role mappings; randomized cluster keys; password-protected enrollment; client-certificate and CA support for dashboard-to-manager connections; removal of older broad-access tools; and indexer multitenancy disabled by default.

Export the active security configuration before migration. Files on disk may be stale because effective settings live in the indexer’s security index. Review users, roles, role mappings, and authentication domains before creating the 5.x equivalents.

indexer-security-init.sh can upload local security files and overwrite changes made through the UI or API. Treat it as a controlled change requiring a backup and configuration comparison.

Removed components and compatibility

The old forms of ossec-authd, wazuh-agentlessd, wazuh-maild, wazuh-dbd, manage_agents, and agent-auth are removed, along with server OpenSCAP support, some inventory/security-configuration API endpoints, and the manager’s SELinux integration.

Sometimes the capability has a replacement: new enrollment services, Notifications, and Content Manager cover parts of the old functionality. Other uses, such as agentless monitoring tied to an old daemon, may need redesign.

Inventory all dependencies on /var/ossec, API endpoints, CLI calls in Ansible/runbooks, custom rules/decoders/lists/integrations, Filebeat or Logstash, wazuh-maild, Active Response, dashboards/reports/patterns, identity providers and tenants, and consumers of alerts.json or old indices. This inventory determines the actual project scope.

Book a technical assessment of your 4.x environment, compatibility gaps, pilot, and rollback plan. We are preparing dedicated migration guidance and a migration webinar alongside our regular Wazuh sessions.

Platform requirements and sizing

The 5.x documentation targets 64-bit Linux on x86_64/AMD64 and AARCH64/ARM64, listing Amazon Linux 2023, Ubuntu 24.04/26.04, and RHEL 9/10 for central components. Do not assume an older distribution is supported simply because 4.x ran on it.

The documented per-component figures are:

The all-in-one quickstart uses a different combined profile: 4 vCPUs, 8 GiB, and 50 GB for 1–25 agents; 8 vCPUs, 16 GiB, and 100 GB for 25–50; and 8 vCPUs, 16 GiB, and 200 GB for 50–100, with a modelled 90-day storage horizon. These are reference profiles, not guarantees for arbitrary security telemetry.

Do not transfer capacity tables mechanically from 4.x to 5.x. Events and findings are stored separately; source types, audit settings, raw/discarded streams, replicas, shards, compression, state indices, CTI, snapshots, and recovery headroom all affect capacity. A representative pilot is more useful than agent count alone.

Measure average/peak EPS by source, daily primary-data growth, event-to-finding ratio, state/CTI size, detector execution time, heap/CPU/queue pressure, indexing latency, retention, and restore time. Use those results to choose all-in-one, a separate indexer, or distributed clusters.

Migration: a new system beside the old one

Keep the 4.x deployment available, create a new 5.x deployment, and migrate or recreate only supported components. Central components cannot be upgraded in place because OpenSearch 3.x, WCS, data streams, Content Manager, detection, and configuration change together.

4.x inventory → backups → new 5.x lab → content conversion → parallel validation
→ historical data → agent registrations/groups → pilot agents
→ compare events/findings → cutover → controlled 4.x retirement

What moves, and what is recreated?

Keep historical data separate

The migration design supports indexed data from Wazuh 4.4.0 or later. Source and destination need access to a snapshot repository. Snapshot only required Wazuh data indices, without global state or system indices.

Register the destination repository read-only, restore with a prefix such as restored_, and create a separate pattern. The restored documents keep their old mappings and timestamps; new 5.x data does not flow into them and they are not automatically converted to WCS.

Queries spanning old and new data must account for different fields and types. Keep the datasets separate or design an explicit transformation with documented mappings and limitations. Do not restore .kibana*, .opendistro*, the security index, or global cluster state into 5.x.

New manager paths and configuration

Wazuh 4.x: /var/ossec/etc/ossec.conf
Wazuh 5.x: /var/wazuh-manager/etc/wazuh-manager.conf

Use the old file as an inventory, not a replacement configuration. Notifications replace <alerts>; dashboard-managed Active Response replaces <command> and <active-response>; Content Manager replaces <ruleset>. Agent-related rootcheck, FIM, SCA, inventory, and local-file settings move out of their former manager configuration roles. Manager paths change to /var/wazuh-manager.

Validate syntax, daemon logs, indexer connectivity, and cluster state. A successful service start does not prove that normalization and findings work.

Install the dashboard fresh

The 4.x configuration path /usr/share/wazuh-dashboard/data/wazuh/config/wazuh.yml is replaced by /etc/wazuh-dashboard/opensearch_dashboards.yml. hosts becomes wazuh_core.hosts, health checks use healthcheck.checks_enabled, and older cron/monitoring options disappear. Advanced Settings may be tenant-specific or globally overridden.

Import custom saved objects selectively, not the vendor's entire 4.x dashboard set. Repair old patterns and field references and inspect every panel over a range containing data. Handle each tenant separately where applicable.

Custom detection content is its own workstream

For each integration, retain source-file checksums, representative and problematic logs, a field map, new YAML in Draft, positive/negative Log Tests, a same-input comparison of 4.x alerts and 5.x findings, downstream notification/dashboard/response dependencies, and an approved promotion to Custom. Syntax-only conversion can silently change detection coverage.

Preserve agent identity

Import active registration rows from client.keys through the 5.x manager API before switching addresses. Preserve the ID, name, IP restriction, and key; then change the agent’s manager address and restart it.

A 4.x agent can communicate with a 5.x manager during transition, but FIM, SCA, inventory, Active Response, and Vulnerability Detection are not fully supported until the agent reaches 5.x. Treat mixed versions as a short pilot stage, not the target architecture.

Agents older than 4.14 require a two-stage remote upgrade through 4.14.x. Test each OS/package path used by your organization, including pending reboots and low disk space, before a broad rollout.

Validate before cutover

• Expected component builds and healthy clusters.
• Normalized data arriving in every required category.
• Loaded Standard/Custom policies and consistent content versions.
• Expected WCS and finding results from representative replay logs.
• Explained differences in event/finding counts.
• Full FIM, SCA, inventory, and vulnerability synchronization after agent upgrades.
• Working custom dashboards with correct fields and patterns.
• Delivered notifications without sensitive-data leakage.
• Tested response execution, reversal, and emergency disabling.
• Verified AI RBAC/privacy and links to source evidence if AI is enabled.
• A completed snapshot/restore test.
• A defined rollback window with 4.x still available.

How to prepare now

Until the final release, keep Wazuh 5.0 in an isolated lab. Plan production migration, but wait for the final release, its support matrix, and successful environment-specific testing.

Prepare a supported 4.14.x source environment, inventory custom content and automation, collect anonymized replay samples, export dashboards, measure EPS/retention, check OS support, design PKI/enrollment-secret handling, decide what may leave through an AI provider, and convert one integration end to end in a parallel lab.

Want to see the changes in practice? Alongside regular Wazuh webinars, we are preparing a Wazuh 5.0 demonstration and a dedicated upgrade/migration session, including the difficult parts of moving an existing 4.x deployment. See our webinar schedule.

Summary

Wazuh 5.0 standardizes data with WCS, separates normalization from detection, and moves content management, rules, reporting, notifications, and responses closer to the indexer. Draft → Test → Custom gives custom detection content a managed lifecycle. Sigma rules and enrichment improve portability and context, while Case Management, Incident Response, and AI Assistant broaden the analyst workflow.

The trade-off is substantial incompatibility with 4.x. Plan a parallel deployment with content conversion, evidence-based testing, and controlled agent cutover—not just package updates. Start the inventory and lab now; base production decisions on release notes and your own test results.

Downloads and further reading

• Wazuh 5.0.0 Beta 5 test release.
• Official 5.0 release-notes source.
• New data-analysis documentation.
• Official 4.x-to-5.x migration guide.
• Indexer-plugin release notes.
• Audited manager/Engine source tag.
• Audited indexer-plugin source tag.
• Introducing Wazuh CTI.

As specialists in Wazuh, SIEM, infrastructure, and automation, we can help assess readiness, design the architecture, convert custom content, build a pilot, and manage migration. Contact initMAX to discuss your current environment and the path to Wazuh 5.0.