How to Install Wazuh: Step-by-Step Deployment Guide for NIS 2

A Wazuh deployment for NIS 2 should start from architecture and evidence requirements, not from an installation script. The practical objective is to collect the right events, protect the SIEM itself, retain usable evidence, and connect alerts to incident-response procedures.

Sources: Wazuh installation guide, Wazuh Linux agent deployment, Wazuh architecture, ACN baseline obligations determination.

Key takeaways

• Use the official Wazuh documentation for current commands and package versions.
• Choose all-in-one only for labs or small environments; separate components for production when availability matters.
• Harden administrator access, TLS, backups, and retention before onboarding sensitive log sources.
• Agent rollout should follow asset criticality, not convenience.
• Validation must include alert generation, log retention, backup restore, and escalation workflow tests.

Prerequisites: hardware, software, and operating model

Before installation, define expected endpoint count, log volume, retention target, administrator model, backup location, and escalation workflow. Wazuh documentation supports central components on a single host or distributed configurations. NIS 2 programs should also define who reviews alerts and who decides escalation.

Deployment architectures

Install the central Wazuh components

The official installation guide documents the sequence: install the Wazuh indexer, install the Wazuh server, then install the Wazuh dashboard. For a lab, Wazuh also documents a quickstart all-in-one approach. Treat the following as an execution pattern, not a substitute for the official guide.

# Example pattern only: verify current commands in Wazuh docs before use
curl -sO https://packages.wazuh.com/4.x/wazuh-install.sh
sudo bash ./wazuh-install.sh -a

For production, prefer the step-by-step central-components workflow. Store generated credentials securely and rotate them according to your internal privileged-access policy.

Configure the indexer and dashboard

After deployment, validate dashboard access, administrator accounts, TLS certificates, index health, disk allocation, and authentication settings. The dashboard is not just a viewer. It becomes part of the regulated evidence chain, so access logs and admin roles should be controlled.

Deploy Wazuh agents

Wazuh agents can be deployed to Linux, Windows, macOS, and other supported platforms. Start with systems that support essential services, identity infrastructure, internet-facing assets, and security tooling.

# Linux agent pattern from official package workflow
WAZUH_MANAGER="wazuh-manager.example.local" apt-get install wazuh-agent
systemctl daemon-reload
systemctl enable wazuh-agent
systemctl start wazuh-agent

Use groups for server class, business service, environment, and criticality. Do not mix production and test endpoints without clear tagging.

Initial configuration: groups, rules, decoders

Initial configuration should define agent groups, baseline rules, alert severity thresholds, and log source coverage. Wazuh rules and decoders are powerful, but unmanaged changes can create noise or blind spots. Keep a change log for every tuning decision.

Hardening the installation

• Restrict dashboard administration to named users and MFA where available.
• Limit network exposure to required ports only.
• Separate administrator duties from daily analyst duties.
• Protect Wazuh configuration backups and credentials.
• Document retention and deletion settings against legal and operational needs.

Backup and disaster recovery

For NIS 2, log and SIEM availability matters during incidents. Back up configuration, certificates, dashboards, rules, and relevant indexes. Test restore, not only backup creation. Recovery evidence supports resilience expectations and internal assurance.

Validate the deployment

1. Confirm all priority agents are connected.
2. Generate controlled test events and verify alert visibility.
3. Check retention and index growth against storage planning.
4. Test syslog ingestion for network devices where needed.
5. Run a backup restore test in a non-production environment.
6. Map alert escalation to the incident-response procedure.

Pre-build design decisions

Before running installation commands, document the design decisions that affect compliance evidence. Decide whether production data can leave the organization, whether the deployment requires high availability, which administrators can access the dashboard, and which systems will be monitored in the first wave. These decisions should be approved before onboarding critical log sources.

Production hardening checklist

1. Place Wazuh components in a controlled network segment.
2. Restrict inbound management ports to administrator networks.
3. Use named accounts and avoid shared administrator credentials.
4. Protect certificates, enrollment secrets, and generated passwords.
5. Define operating-system patching windows for Wazuh nodes.
6. Enable backup for configuration and critical indexes.
7. Document emergency access and recovery procedures.

Agent rollout by criticality

A strong rollout does not start with every endpoint. It starts with systems that support essential services. Typical first-wave targets are domain controllers, identity providers, VPN concentrators, internet-facing servers, backup systems, privileged-access hosts, and production application servers.

After the first wave, expand to employee endpoints, cloud workloads, container hosts, and network devices. For each wave, keep a simple acceptance test: agent connected, expected logs visible, alert test completed, owner confirmed, and rollback path documented.

Troubleshooting checklist

• If agents do not appear, verify manager hostname, port reachability, enrollment, and local service status.
• If dashboard login fails, check certificates, Wazuh API connectivity, and indexer health.
• If events are missing, confirm localfile configuration, syslog listener settings, and source firewalls.
• If disk grows too quickly, review archive settings, noisy sources, retention, and index lifecycle.
• If too many alerts appear, tune rules through a documented change process, not ad hoc suppression.

NIS 2 validation test matrix

Detailed deployment runbook

A production runbook should be written before installation and updated during implementation. It should include component hostnames, network ranges, ports, certificates, privileged accounts, backup paths, log-source onboarding sequence, rollback criteria, and validation tests. This runbook becomes evidence that the deployment was controlled.

Step 1: environment preparation

Prepare operating systems, DNS names, time synchronization, firewall rules, disk partitions, package repositories, and administrator access. Time synchronization is important because alert timelines lose value when endpoint and server clocks drift.

Step 2: central component deployment

Install central components according to the official Wazuh workflow. Record package versions, configuration files changed, generated credentials, certificate locations, and any deviation from the official documentation. If the team chooses all-in-one, record why that design is acceptable for the environment.

Step 3: secure administration

After dashboard access is working, reduce default exposure. Replace temporary credentials, review administrator roles, document emergency access, and restrict management interfaces. Administrator actions should be traceable because SIEM configuration changes can affect detection and evidence integrity.

Step 4: source onboarding

Connect only the first approved wave of systems. For each source, record expected log types, business owner, technical owner, criticality, and acceptance test. A source is not complete when the agent is installed. It is complete when expected events are visible and explainable.

Step 5: operating acceptance

Before go-live, run a short acceptance session. Generate controlled authentication, privilege, malware-test, service-failure, and syslog events where safe. Confirm that the team can see the event, understand the alert, assign an owner, and close the ticket with evidence.

Command safety notes

Command snippets in public articles should never be copied blindly into production. Wazuh documentation changes over time, package versions evolve, and production environments differ. Treat snippets as a structure for the runbook. The execution source of truth remains the official Wazuh documentation reviewed on the deployment date.

Post-installation operating cadence

For organizations that prefer a managed approach over self-deployment, Aegister offers the Virtual CISO service with security operations delivered through the Cyber Console platform: centralized log review, NIS 2 control mapping, and CSIRT-ready incident workflows.

Series navigation

• introduction to Wazuh
• Wazuh log management for NIS 2
• Wazuh vs commercial SIEM
• NIS2 detection and event monitoring
• operational registers and logs

FAQ and troubleshooting

Should every asset get an agent immediately?

No. Prioritize critical systems, identity services, internet-facing assets, and systems supporting NIS activities. Expand in controlled waves.

Can Wazuh receive network-device logs?

Yes. Wazuh documentation describes syslog collection for devices where agents cannot be installed.

What should be tested before production use?

Agent connectivity, alert visibility, syslog ingestion, backup restore, access control, and escalation procedures.

Official sources

• Wazuh installation guide
• Wazuh Linux agent deployment
• Wazuh syslog configuration
• ACN baseline obligations determination
• ACN guide to baseline specifications