Wazuh security hardening starts with the four components that hold your data
Hardening a Wazuh deployment means securing the monitoring platform itself: certificates between components, changed default credentials, restricted access to the API and dashboard, controlled agent enrollment, and protection for the alert data stored in the indexer. A security team that has stood up Wazuh, or is about to, needs to know whether the platform can be trusted once an attacker is assumed to be probing it. The output is only as credible as the stack that produces it, so this work comes before anyone relies on the alerts for investigations or evidence.
The difficulty is that trust in Wazuh is spread across four components, and each holds a different piece of the chain. The Wazuh indexer stores alerts and is the record you will search during an incident. The Wazuh server analyzes agent data with decoders and rules, and it also manages agent configuration and upgrades remotely, which makes it a powerful point of control. The Wazuh dashboard is the web interface where administrators sign in. The agents on endpoints report to the server and enroll with it. An attacker who controls any one of these can suppress alerts, alter stored events, or register a rogue agent, and the activity they want hidden may never reach your analysts.
A deployment that installs and reports correctly is not automatically hardened. Installation guides set up working defaults to get the platform running, and some of those defaults, including accounts and certificate arrangements, are meant to be replaced or reviewed before production use. Confirm against the installation documentation for the exact version you deploy which credentials, certificates and listening interfaces are created at install time. Then record who can reach each component over the network, which administrative accounts exist, and which hosts are permitted to enroll agents. That inventory is the starting point for every control in this section.
This section is not about writing detection content or connecting the dashboard to an identity provider. Building custom rules, decoders and alert tuning is covered in the customization topic, and single sign-on with SAML identity providers is covered separately. Hardening sets the baseline those projects depend on, so it is worth completing before agents are rolled out widely or custom content is layered on top. Plan the hardening work as its own step with a named owner, and ask any implementation partner to show how each control will be verified, not only configured.
Which Wazuh components expose hardening surfaces
A Wazuh deployment has four components, and each one accepts connections, stores data or holds trust that an attacker could use. Read the cards as a map of where to set boundaries before you change any configuration, because the server's control over agents affects every endpoint it manages.
Wazuh indexer and its API
The indexer is the full-text search and analytics engine that stores alerts. Its API surface is where stored events are read, queried and changed, so access to it should be limited to the components that need it. A compromise here could let an attacker read stored events, alter or delete alert records, or suppress evidence of their own activity. Confirm the API ports, authentication methods and default access settings for your release in the official documentation before you set access rules.
Wazuh server and agent ports
The server analyzes agent data with decoders and rules and accepts inbound agent connections. It can run as a cluster, and its listening ports and cluster communication paths need to be restricted to known sources. A compromised server could change rules so that detections stop firing, or quietly drop events from specific hosts. Confirm the ports and cluster settings for your release, and check which networks are allowed to reach them.
Wazuh server as a trust anchor for agents
The server can run as a cluster and manages agent configuration and upgrades remotely. A compromised server therefore affects every enrolled agent, since it can push altered configuration, change which log sources are collected or alter agent settings across the fleet. Treat the server and its cluster nodes as the highest-value targets in the deployment, and limit who can administer them and how their changes are reviewed.
Wazuh dashboard login
The dashboard is the web interface that analysts and administrators use to search alerts, change settings and manage users. It can authenticate against the internal user database or through SAML single sign-on, and each path has its own account and role risks. A compromised dashboard login could expose alert data, let an attacker change rules or agent groups, or create accounts. Review which roles exist, remove default credentials, and confirm how sessions and failed logins are handled in your release.
Agent enrollment credentials
Agents register with the server using enrollment credentials, and whoever holds those credentials can attempt to add a rogue endpoint to the fleet. A leaked enrollment secret could let an attacker receive configuration, submit forged events or hide a host that should be monitored. Decide how enrollment is authorized, where the credentials are stored during automated rollouts, and how they are rotated. Confirm the enrollment options and password handling for your release.
Certificates between components
Communication between the indexer, server, dashboard and agents relies on certificates and keys that establish which component is talking to which. Weak or unmanaged certificates make it easier to impersonate a component or intercept traffic on the network. Plan who issues and renews these certificates, where private keys are kept, and how a key is replaced after suspected exposure. Confirm the certificate tooling and file layout for your release, since they differ between installation methods.
Which hardening choices fit your environment and what they cost to run
This table compares the main Wazuh hardening choices for certificates, dashboard exposure, agent enrollment and alert storage. Read each row by matching the option to your network and audit model, then weigh the recurring operational work it adds. The main takeaway is that each stronger control moves cost from installation into ongoing renewal, distribution, access and change control work.
| Decision | When it fits | Operational cost to run |
|---|---|---|
| Generated certificates | Small or lab estates with one administrator and no external CA policy | Low setup; rotate by re-running generation and redistributing files to every component and agent |
| Internal CA certificates | Regulated environments where assessors expect certificates from your own PKI | Renewal tracked in your CA process; certificate chains must reach every agent and component |
| Dashboard on internal network only | Operators reach the dashboard from a segmented management network | Low; relies on network controls and jump hosts that need their own access reviews |
| Dashboard behind reverse proxy | Remote analysts or wider user populations need access with restricted routes | Proxy configuration, TLS renewal, access logging and change control for every route change |
| Agent enrollment with shared credentials | Small, short-lived or tightly controlled fleets where one secret is acceptable | Low setup; a leaked secret requires re-enrolling affected hosts and rotating the shared value |
| Per-host or scripted enrollment with rotation | Fleets managed through Ansible, Puppet or golden images with frequent host changes | Automation to maintain, secret distribution to build pipelines, and rotation schedules to test |
| Alerts stored on the indexer only | Short retention needs where operators query live data and no export is required | Low; retention and disk growth still need monitoring and review as event volume rises |
| Indexer storage with snapshot and export controls | Retention rules, legal holds or evidence requests that need copies outside the cluster | Snapshot repository management, restore testing, access to export paths and encryption key handling |
How to sequence Wazuh security hardening without locking out your own team
This sequence hardens a self-hosted Wazuh deployment in an order that keeps your administrators able to reach the indexer, server and dashboard at every stage. Each step closes with a check that proves the change worked before the next one starts. The result is a deployment with inventoried and rotated credentials, controlled access paths and protected alert data.
Inventory version, defaults and certificates first
Your team, or an implementation partner, lists the installed Wazuh version on every indexer, server and dashboard node and checks it against the 4.14 patch release notes. Next, record every default account, API user and service credential, along with every certificate, its issuer and its expiry date. Keep the inventory dated and have someone other than its author verify it against the live nodes. The step is done when every component and credential appears in the inventory and the check is signed off. Confirm the exact listing commands in the official 4.14 documentation.
Replace or verify certificates between components
Work through the indexer, server and dashboard in the order the official 4.14 documentation gives for certificate changes, and confirm that each component trusts the certificate authority used by the others. Stage every change in a test environment first. Changing certificates or credentials in the wrong order can break cluster communication, and a dashboard that cannot reach the indexer often looks like a login problem. The step is done when each component restarts cleanly, every internal connection verifies its peer certificate, and a test query returns results in the dashboard.
Change default passwords and service accounts
Replace every default password for indexer, server API and dashboard users, and rotate the service accounts that other systems depend on. Make these changes in the same staged order used for certificates, because some components store credentials in their own configuration files. Write each new credential into a secrets store with a named owner and a rotation note, and limit who can read it. The step is done when the default logins are refused, each service account authenticates from its own component, and the secrets store holds an entry for every account in the inventory.
Restrict API and dashboard access to named networks
Limit access to the Wazuh API and dashboard to the network ranges and administrator roles that need them, using firewall rules and the role model in the dashboard. Before you tighten the rules, keep at least one break-glass administrator path and test it, so a misconfigured rule cannot lock out the whole team. Document the approved network ranges and roles. The step is done when a test client outside the approved ranges is refused, an approved administrator can log in and complete an administrative action, and the break-glass path has been tested and recorded.
Harden agent enrollment and group assignment
Review how agents register: who holds enrollment credentials, which hosts may enroll, and which agent group new agents receive by default. Remove any enrollment secret that is shared widely or stored in plain text in build scripts, and scope enrollment so new agents land only in groups that carry the intended configuration. Write the procedure down for the team that will deploy agents later. The step is done when a host without a valid enrollment credential cannot register, a test agent enrolls into the intended group only, and the procedure is documented.
Protect stored alert data and snapshot access
Set filesystem permissions on indexer, server and dashboard data and configuration directories so that only the service owners can read them. Confirm that transport encryption is active between components and for client connections, then restrict who can reach the snapshot repository that holds archived alerts. The step is done when permissions match the inventory, encrypted connections are verified, and a test snapshot restores into a separate environment without widening access to the repository.
What drives the effort of Wazuh security hardening
This table lists the factors that change how much work it takes to harden a Wazuh deployment, with a practical way to keep each one under control. Read each row as a lever: the more of a driver you have, the more certificates, credentials, change windows and evidence you will maintain. The main takeaway is that standardizing early on enrollment, configuration and certificate authority reduces both the one-time hardening work and the recurring upkeep.
| Driver | Why it changes effort | How to keep it down |
|---|---|---|
| Number of nodes and indexer cluster members | Each indexer, server and dashboard component needs its own certificate and transport settings, and each added node adds a change window for upgrades and certificate renewal. | Keep the node count to what capacity requires, script certificate issuance, and schedule rolling changes one node at a time. |
| Number of agents and enrollment methods | Mixed enrollment methods mean several credential paths to secure, audit and rotate, and more places where an agent can enroll without authorization. | Standardize on one enrollment method, restrict enrollment to the intended agent groups, and rotate enrollment credentials on a fixed schedule. |
| Number of environments (lab, staging, production) | Each environment carries its own certificates, passwords, API accounts and configuration, so hardening work is repeated per environment and drift can appear between them. | Use one templated configuration for all environments with per-environment variables, and test hardening changes in staging before production. |
| Custom integrations that read the API or the indexer | Scripts and tools that call the Wazuh API or query the indexer need service accounts, scoped roles and certificate trust, and they can break when access rules change. | Create dedicated least-privilege service accounts for each integration, document the roles each one needs, and review them after every upgrade. |
| Identity provider integration | SAML single sign-on adds certificate exchange, group-to-role mapping and a dependency on the identity provider's own security settings. | Map identity provider groups to a small set of Wazuh roles, document the mapping, and keep local administrator access under a break-glass procedure. |
| Compliance evidence requirements | Assessors may ask for proof of certificate management, access reviews, configuration baselines and change records, which adds collection and retention work. | Define the evidence list early, generate it from configuration management and logs where possible, and confirm the required format with your auditor. |
| Air-gapped or offline deployment | Offline installation and an offline vulnerability repository require internal package and update mirroring, and each update must be transferred and verified manually. | Plan a repeatable transfer process with checksums, keep an internal mirror schedule, and document who approves each import. |
| Internal certificate authority | Without a documented internal certificate authority, certificate issuance, renewal and revocation become ad hoc, which is a common source of outages and audit findings. | Document the internal certificate authority, define issuance and renewal procedures, and set a calendar reminder well ahead of each certificate expiry. |
How hardening changes in single node, clustered and air-gapped deployments
On a single-node deployment, the indexer, server, dashboard and any co-located components run on one host. The trust chain is short: there are fewer certificate relationships to issue and fewer network paths to restrict between components. The trade-off is that one host is a single target and a single point of failure, so host-level controls carry more weight than they do in a distributed design.
Steps that change:
- Certificate issuance is simpler, but the host's own filesystem permissions and the protection of the generated certificate private keys become the main control point.
- Inter-component traffic stays on the loopback or local interface, so restrict listening addresses to what the dashboard and agents actually need.
- Hardening of the operating system, time sources and backup of the single host becomes a first-order task rather than a shared responsibility.
- Credential rotation for the indexer, server API and dashboard users applies to one set of secrets, which simplifies rotation but concentrates exposure if they leak.
Steps that stay the same:
- Replacing default credentials for all internal and dashboard accounts before the system receives production agents.
- Restricting dashboard and API access to administrative networks and enforcing SSO or strong authentication.
- Securing agent enrollment with enrollment credentials that are scoped and rotated.
- Protecting stored alert data with access control, retention rules and backups.
Before go-live, confirm the host's patch cadence, its backup restore test and which local accounts can reach the configuration files.
A clustered deployment runs multiple Wazuh server nodes and indexer nodes. Hardening shifts from one host to a set of nodes that must trust each other. Certificates must be distributed to every node consistently, and any change must be applied in a way that keeps the cluster available. The security posture depends as much on the process for change as on the settings themselves.
Steps that change:
- Certificate distribution: each node needs the certificates it presents and the CA material it trusts, so plan how certificates are generated once, copied securely and tracked per node.
- Rolling changes: certificate renewal, credential rotation and configuration edits are applied node by node, with cluster health checked between steps.
- Network segmentation between nodes: restrict the cluster communication ports to peer nodes and to the load balancer or agent-facing addresses.
- Access to node configuration: every node is a place where configuration can be altered, so access controls and change records apply to each one.
Steps that stay the same:
- Replacing default credentials across all indexer and dashboard accounts, now recorded in one inventory that covers every node.
- Restricting dashboard and API access and enforcing SSO or strong authentication.
- Scoping agent enrollment credentials and rotating them on a schedule.
- Protecting alert data through access control, retention and backups that are tested by restore.
Before the first rolling change, confirm with your team how the cluster behaves when one node is taken out of service and which certificate renewal steps require a restart.
In container-based deployments, the orchestrator or container runtime takes on part of the hardening work. Secrets, network reachability and image sourcing are controlled through the platform, not only on individual hosts. The security boundary moves from the operating system to the cluster configuration, the image pipeline and the secret store. Confirm the exact capabilities of your chosen platform before you design controls around them.
Steps that change:
- Secrets: credentials and certificates are supplied through the orchestrator's secret mechanism rather than plain files baked into images or configuration.
- Image provenance: pull images only from a registry you control, verify where they came from, and record the version deployed against the Wazuh release in use.
- Network policies: restrict pod or container traffic to the specific components that need it, using the network controls your platform provides.
- Persistent storage for the indexer: confirm how volumes are encrypted, backed up and restored on your platform.
Steps that stay the same:
- Replacing default credentials before any agent connects.
- Restricting dashboard and API access and enforcing SSO or strong authentication.
- Scoping and rotating agent enrollment credentials.
- Controlling access to alert data, applying retention rules and testing backups.
Before deployment, confirm with your platform team which secret store, image registry and network policy features are available and approved, and who may change them.
Air-gapped deployments have no internet connectivity, so anything the system normally fetches online must be brought in by hand and checked before use. The Wazuh offline installation guide covers installation without internet access, and vulnerability detection can use an offline vulnerability repository in place of the Wazuh Cyber Threat Intelligence platform. Provenance and integrity checks move from automated steps to documented manual procedures.
Steps that change:
- Installation media and packages are transferred through an approved process, and each transfer is verified against recorded checksums or signatures.
- Certificates are generated and distributed locally, with the signing and custody process documented for auditors.
- The offline vulnerability repository must be refreshed through a controlled import, and the import date recorded so results can be interpreted.
- Updates and patches arrive as reviewed bundles, so patch testing and approval happen before transfer.
Steps that stay the same:
- Replacing default credentials and restricting dashboard and API access.
- Securing agent enrollment and rotating enrollment credentials.
- Protecting stored alert data with access control, retention and tested backups.
- Monitoring the platform itself and reviewing its logs.
Before planning transfers, confirm with your security team which media, approval steps and checksum method your environment requires, and how long a vulnerability repository import takes in your process.
Wazuh security hardening controls for the API, dashboard and agents
Hardening a Wazuh deployment means securing each component and the paths between them. The controls below cover trust between components, the credentials and network paths that reach the API and dashboard, how agents join the manager, and how stored alerts are protected. Confirm exact configuration file names and options for the 4.14 release in the official Wazuh documentation before changing a production system.
Certificates between components
Wazuh components authenticate and encrypt traffic with certificates on the indexer, server, dashboard and API connections. Leaving default or self-generated certificates in place weakens trust between nodes and makes it harder to spot a impersonated component. Check who issues the certificates, where private keys are stored, how long each certificate is valid, and who can read those keys on each host. Write a renewal procedure before the first certificate expires, because an expired certificate can interrupt dashboard access or agent connections.
Replacing default credentials
Installations create built-in accounts for the dashboard, indexer and API, and anyone familiar with a default setup may know their starting passwords. An unchanged default can give an attacker administrative access without exploiting any vulnerability. Change these passwords during installation, store them in a secrets manager, and confirm which built-in accounts stay enabled. Review service accounts used by automation so that shared passwords do not persist in scripts, configuration files or chat history.
Restricting API access by network and role
The Wazuh API manages agents, configuration and rules, so reachability from a broad network segment lets an attacker change detection logic or enrollment settings. Limit which source addresses can reach the API and place administrative clients on a management network. Assign each API user the narrowest role that fits the task, and remove accounts for people who have left. Test every role with a read call and a write call so you know exactly what it can change.
Limiting dashboard exposure and sessions
The dashboard gives access to alert data and management functions, so it should be reachable only from networks used by the security team. Publish it through a reverse proxy or load balancer you control, enforce TLS, and set session lifetimes and idle timeouts that match your access policy. Review how dashboard accounts are created and which roles can open administrative views. SAML single sign-on is a separate topic, but dashboard access should be reviewed here as part of hardening.
Controlling agent enrollment credentials
Agents join a manager through enrollment, and anyone holding the enrollment credential can register an endpoint that receives configuration and reports alerts. Decide which teams may enroll agents, whether enrollment requires a password in your release, and which group new agents join by default. Store any enrollment password in a restricted location, rotate it on a set schedule and after staff changes, and review agent listings for registrations you did not expect. Confirm the options for the 4.14 release in the official documentation.
Protecting stored alert data
The indexer stores alerts that can contain usernames, hostnames, IP addresses and command lines, so a copy of its data can reveal much of your environment. Restrict index access to roles that need it and decide with your security and compliance owners whether data at rest must be encrypted. Confirm how encryption is provided by your storage layer. Register snapshot repositories only on protected storage with restricted access, because a readable repository exposes the same data outside the cluster.
How to verify Wazuh security hardening and confirm it fails safely
A hardened Wazuh deployment is only as trustworthy as the tests that show its controls refuse what they should refuse. For each control in the hardening baseline, the verification question is the same: can a party that should be blocked still get in? Start with the agent channel. Enroll a test endpoint, then revoke or rotate its credential and confirm the agent cannot reconnect to the Wazuh server. Repeat with an old enrollment password or a copied agent key from a retired host. Each attempt should fail, and the server should record the rejection. Do not rely on the agent showing a disconnected status alone, because a stale status can look like a healthy link that has simply not yet timed out. Next, test the indexer and the API surfaces directly, without the dashboard in the path. Send requests to the Wazuh indexer with no credentials, then with the default credentials shipped with the installation, and confirm both are rejected. Do the same against the Wazuh server API and the dashboard login. Then test network restrictions from a host outside each allowed range. The dashboard and API should refuse the connection at the network layer or the application layer, and you should confirm which layer enforces it, since that determines where the fix belongs if a test fails. Certificates need their own checks. For each pair of components (agent to server, server to indexer, dashboard to indexer, and any cluster peers), confirm that the TLS handshake validates the chain against your intended certificate authority and that hostnames match. Test with a certificate issued by a different authority, an expired certificate, and a certificate for the wrong host name. Each should be refused. Confirm your expected behavior with the Wazuh documentation for your exact release line before writing the test cases, because configuration keys and file locations change between versions. The most important tests concern failure modes. Restart each component, and take one indexer or server node offline in a cluster, then confirm that the service does not fall back to a weaker path such as plain HTTP, default credentials, an unauthenticated listener or an unvalidated certificate. A fallback that appears only during recovery is a common gap, and it is easy to miss when testing only the steady state. Run these tests in staging with a deliberately wrong certificate or credential, and confirm the failure is logged and visible in the monitoring you already run. A rejection that nobody sees is a control gap, not a passing test. Keep a dated record of every test: the control tested, the configuration version, the input used, the observed result, the log location that showed the failure, and the person who reviewed it. This record is your evidence for internal reviewers and for compliance assessors, who will ask how you know the controls work. Rerun the suite after every Wazuh patch release and after any change to certificates, enrollment or network rules. Ask any implementation partner to deliver the test scripts and results in this form, and confirm in writing which tests they will run in your environment.
Questions teams ask before hardening Wazuh themselves or hiring help
Can our own team harden Wazuh without a partner?
Yes, if the team already operates the relevant pieces and can make changes in stages. The skills that matter are certificate management across the indexer, server, dashboard and agents, identity and access administration for the dashboard and API, and Linux hardening for the hosts that run each component. The schedule matters as much as the skills. Each change touches a running system, so the team needs time to test in staging, schedule a maintenance window and roll back if an agent stops reporting. If one of these skills is missing or the team cannot dedicate time, a written scope with a partner can close that gap. Ask the partner which of these areas they would hand over to your staff.
What drives the cost of hardening a Wazuh deployment?
Cost follows the size and shape of the environment and the evidence you need at the end. The main drivers are:
- Number of indexer, server and dashboard nodes, and whether the server runs as a cluster
- Number of agents and the operating systems they run on
- Number of environments, such as development, staging and production, each needing the same controls
- Integrations, including SAML single sign-on, ticketing, and any agentless devices fed by syslog
- Compliance evidence needs, such as mapping controls to a framework and collecting proof for an assessor
- Whether the work includes security testing of the hardened deployment
Ask for a quote that lists each item separately, so you can see what is one-time work and what recurs.
How long does Wazuh hardening take to complete?
The duration depends on the environment and on when changes are allowed. Timing is shaped by the number of components and environments, how many agents must be re-enrolled or reconfigured, the change approval process, and the maintenance windows available to you. Work done in production usually moves at the pace of those windows, not the pace of the engineers. Do not accept a general estimate. Ask for a written scope that lists the phases, the systems in each phase, the approvals needed and the dates on which your staff must be available. Your own change calendar will shape the plan more than any standard sequence.
What does the work need from our team?
Hardening needs access and decisions from your side, not only engineering time. Plan to provide:
- Access to staging and production, with the rights needed to change configuration on each component
- A change approval path that can sign off each phase in advance
- Named owners for secrets, including certificate authority material, service account passwords and API credentials
- A maintenance window for each production change, with a rollback plan
- Someone who can confirm agent behavior and alert flow after each change
Missing owners for secrets are a common cause of delay, because nobody can approve replacing a credential that other systems depend on.
What changes after Wazuh is hardened?
Hardening is a state you must keep reviewing, because the 4.14 line receives patch releases roughly every one to two months. Wazuh shipped 4.14 patch releases on 17 March, 23 April, 1 July, 29 July, 23 September and 14 October 2026. After each upgrade, review:
- Certificates, their validity periods and the trust chain between components
- Default and service credentials, and any that an upgrade may have reset
- API and dashboard access settings, including role mappings
- Agent enrollment settings and the secrets used to register new agents
- Custom rules and decoders, which may need retesting
Ask the team who will own this review after go-live, and whether that work is in your staff's time or a support arrangement.
Which parts of a Wazuh deployment should we harden first?
Start with the components that hold the most sensitive data and the most access. In most deployments, that means:
- The indexer, which stores alerts and is the main target for data exposure
- The Wazuh server, which holds agent keys and manages agent configuration remotely
- The dashboard and API, which control who can read alerts and change settings
- Agent enrollment, since an unprotected enrollment path lets an unknown host join your monitoring
Certificates between components and replacing default credentials usually come before access restrictions, because later steps depend on them. Confirm the order against the current Wazuh documentation for your version before you schedule changes.
Does hardening include testing that the controls work?
It can, but only if the written scope says so. Ask whether the quote includes:
- Verification that each component only accepts encrypted, authenticated connections
- Checks that default credentials no longer work
- Testing of API and dashboard access from networks that should be blocked
- Confirmation that agents still enroll, report and receive configuration
- Security testing of the hardened deployment, which is a separate activity from configuration work
DeployOpen runs security testing of applications, APIs and infrastructure, and prepares systems and evidence for compliance assessments, but it does not issue audit reports or certifications. Independent auditors and certification bodies perform those.
What to monitor, back up, upgrade and document after hardening
Hardening a Wazuh deployment is a state that drifts unless someone operates it, so the routine after go-live matters as much as the initial changes. Start with expiry and age. Track the expiry dates of certificates on the indexer, the server, the dashboard and any agent-side material, and set alerts well before those dates so a renewal does not become an outage. Track the age of every credential that matters: dashboard and API accounts, indexer internal users, and the enrollment secret used to register agents. Confirm with your vendor documentation how each credential is rotated in your version, because rotation steps differ between components and some require restarts.
Alerting should cover the events that show someone is testing the perimeter. Alert on repeated failed logins to the dashboard and the API, and on enrollment events that register an unexpected agent or fail for a known host. Enrollment is where unknown endpoints would join the environment, so treat unexplained enrollments as incidents until proven otherwise. Confirm which built-in rules cover these events in your release, then tune thresholds against a baseline of normal activity so the alerts are actionable rather than constant.
Backups need to cover more than the indexer data. Back up the server and dashboard configuration, your custom rules and decoders, certificate material, and the credentials needed to rebuild the stack, which should be kept in a secrets store rather than alongside the configuration. Restrict access to these backups to named operators, encrypt them, and keep them outside the cluster they protect. Rehearse restores in staging on a schedule, including indexer snapshot restore and confirmation that agents reconnect afterward. Record the measured restore time from each rehearsal, since that figure is what you will plan around.
Upgrades change the security posture, so hardening must be re-verified after each one. The 4.14 line has shipped patch releases on 17 March, 23 April, 1 July, 29 July, 23 September and 14 October 2026, with 4.14.9 released on 14 October 2026. Each release can alter defaults, certificates or configuration files, so run the verification checks again after every upgrade. Test the upgrade order across the indexer, server, dashboard and agents in staging first, and confirm that order in the current upgrade guide for your version. Keep a record of the versions running in each component at all times.
Five documents should be kept current: a hardening baseline describing the settings you chose and why, a certificate inventory listing each certificate, its issuer, its expiry and its owner, a credential register listing each account, its owner, its rotation date and where its secret is stored (never the secret value itself), a change log of every configuration and version change, and verification results from each review. Assign an owner and a review cadence to each. DeployOpen prepares these records as evidence for your compliance work, but it does not issue audit reports or certifications. Independent auditors and certification bodies make that determination, so ask your auditor early which evidence format they expect.
How DeployOpen scopes, hardens and hands over Wazuh deployments
DeployOpen hardens an existing or planned Wazuh deployment inside your own infrastructure, covering the indexer, server, dashboard and agent enrollment. Work is agreed as a fixed-scope engagement with written deliverables, and ongoing support is available as a retainer.
How we scope
- We review your current topology of indexer, server, dashboard and agents before agreeing the hardening scope.
- The written scope names which components, certificates, accounts and API or dashboard endpoints are covered.
- We confirm the Wazuh 4.14 patch level and whether your environment is internet-connected or offline.
How we build
- We replace default credentials and apply certificates between indexer, server, dashboard and agents.
- We restrict API and dashboard access and configure agent enrollment so only approved endpoints can register.
- We secure stored alert data with access controls and document each setting we change and why.
How we hand over
- You receive configuration documentation, a record of changed settings and the verification steps we ran.
- We walk your operations team through how to repeat the checks after upgrades or certificate renewals.
- Handover covers the rollback steps and the ownership of each credential and certificate in your environment.
How we support
- Ongoing support is available as a retainer for re-checking hardening after Wazuh patch releases.
- Retainers can cover certificate renewals, credential rotation reviews and changes to access rules.
- Confirm with us in the quote which post-handover tasks are included and how requests are logged.
