Wazuh deployment security review

Why a Wazuh deployment security review matters before audit or launch

A Wazuh deployment security review is the check an assessor or customer asks for when they need evidence that the monitoring platform itself is hardened, not only the systems it watches. If a regulator, a customer security questionnaire, an insurer or a product launch asks how your SIEM and XDR platform is protected, the answer should rest on a documented review of the Wazuh server, indexer, dashboard, APIs, user roles and agent enrollment, performed against your actual configuration rather than a default installation.

The reason this matters is structural. A Wazuh deployment collects security events, authentication logs, file integrity data and inventory from across the estate, and it holds connections to many endpoints with privileged reach into them. A server, indexer or dashboard left with default credentials, untrusted or missing certificates, an exposed API or broad administrative roles becomes an attractive entry point, and a compromise there would blind the team at the moment it needs visibility most. The review therefore looks at the monitoring stack as an asset in its own right: who can reach each interface, how traffic between components is encrypted and authenticated, which accounts exist and what they can change, and how an agent proves it belongs to the manager before it is trusted.

The review's focus is defensive. It identifies weakness categories, compares the deployment with Wazuh's published guidance on default passwords, certificates, API security and role-based access control, and produces prioritized remediation the team can act on. Before commissioning it, confirm the Wazuh version in use and whether it is the one your vendor support covers, list every network path to the dashboard and APIs, and decide which evidence your auditor or customer will accept. A clear written scope agreed in advance keeps the review focused on the platform that protects you.

What can be in scope for a Wazuh review

A Wazuh review can cover the whole stack or a defined slice of it, and the boundary matters because the security tool holds credentials, telemetry and privileged access to the hosts it watches. The components below connect through certificates, APIs and enrollment, so the scope should state which of them are tested, which environments they run in, and which accounts and rules of engagement apply.

Wazuh server and manager

The Wazuh server receives events from enrolled agents, runs analysis and rules, and exposes the management interfaces that operators use. Review how it is installed, which service accounts it runs under, how its configuration files are protected, and whether its ports are reachable only from the networks that need them. Confirm the server's certificate setup and which components it talks to in clear text.

Indexer and dashboard

The indexer stores alerts and archived events, and the dashboard is the interface analysts use to query them. Both hold security-relevant data, so the review checks whether default users have been changed, whether certificates are deployed for the indexer and dashboard, and whether the dashboard is exposed beyond the analyst network. Confirm which roles can view, change or export alert data.

Server API and indexer API

Both APIs can change configuration, read data and drive other systems, so they are a common route for unintended access. Scope should cover which API endpoints are reachable, from where, and under which credentials and tokens. Ask the client to list any integrations, scripts or automation that call these APIs, because those are often the least documented paths.

Role and user model

Role-based access control decides who can change agent groups, rules, decoders, users and integrations. Scope the review to the defined roles, the mapping from identity provider groups if one is used, and any shared or service accounts. Confirm with the client which roles are in use today and whether an access review has been run on them.

Agent enrollment path

Enrollment decides which endpoints are trusted to report into the platform. Scope the path from agent package distribution to registration, including how enrollment credentials are issued, stored and rotated, and whether enrollment is restricted to approved networks. Endpoints that are enrolled but unmanaged are a common finding, so include an inventory comparison where the client can provide one.

Hosting layer and rules of engagement

The hosting layer covers the operating systems, containers or virtual machines, network segments, backups and cloud accounts that the Wazuh components run on. Agree in writing which environments, accounts and hours apply, which tests are excluded, and how production data is handled. Scope is agreed in writing before work starts, and any change to it is recorded in writing as well.

How the review runs, phase by phase

The sequence moves from agreed scope to a configuration baseline, then to hands-on testing of exposed interfaces, and ends with a written report and a retest that confirms fixes. Each phase produces an artifact the client can check against its own risk decisions.

Agree scope and the target architecture
DeployOpen and the client agree in writing which Wazuh components are in scope: the manager (server), the indexer, the dashboard, the agents, and any integrations that send or receive alerts. The client confirms which environments are covered, whether the review is a configuration review, an interface test, or both, and which named accounts and hosts testers may use. The step closes when the written scope names every component, its hostnames and network zones, and the testing window. Clients should also confirm the Wazuh version in use, since the review checks against the documentation for that version.
Collect the deployed configuration and inventory
The reviewer gathers the configuration files, certificate inventory, user and role lists, and the network paths between components, using read-only access where possible. The reviewer records which agents are enrolled, how enrollment is authorized, and where the dashboard, indexer and server APIs listen. The output is a baseline inventory that the rest of the review measures against. The client verifies the inventory against its own asset records, and any mismatch becomes a question before testing starts.
Review default credentials and user accounts
The reviewer checks whether the default passwords for Wazuh users have been changed, whether any built-in or service accounts remain active, and whether the password policy and account lifecycle match the client's identity standards. Wazuh's documentation describes how to change these passwords, so the review compares the live state against that guidance. The output is a finding list for each default or shared account, with its owner and purpose. The step closes when every built-in account is either changed, disabled, or documented with a justification.
Verify certificates for server, indexer and dashboard
The reviewer compares the certificate setup against Wazuh's documentation for deploying certificates to the server, indexer and dashboard. Checks cover whether internal traffic uses certificates from a trusted authority, whether certificates have sensible subject names and validity, whether private keys are protected on disk, and whether any component falls back to demo or self-generated material. The output is a certificate table showing each component, its issuer, and its status. The step closes when every component-to-component and browser connection is either verified or logged as a finding.
Test API exposure and role-based access control
The reviewer checks how the Wazuh server API and the indexer API are reachable, which network zones can reach them, and whether they require authentication and the expected roles. Testers then confirm that role-based access control limits users to the data, agents and actions their role allows, following the access model in Wazuh's documentation. Testing is performed against the client's own instance, with the client's permission, and does not attempt to bypass controls beyond what the scope allows. The output is a matrix of roles, permitted actions and observed behavior. The step closes when each role boundary has been tested and any over-permission is recorded.
Test agent enrollment and exposed interfaces
The reviewer examines how agents are enrolled, including who may register a new agent, how enrollment secrets are issued and rotated, and whether an unregistered host could join the fleet. Testers then probe the dashboard and other exposed interfaces for the weakness categories in scope, such as weak session handling, missing transport protection, and unnecessary exposure of administrative paths. Consistent with CIS Controls Safeguard 16.13, which asks for application penetration testing, the work is recorded with the method used. The output is a list of confirmed weaknesses with evidence and affected components. The step closes when each interface in scope has a recorded result.
Deliver the report and remediation plan
DeployOpen issues a written report that lists each finding with its affected component, evidence, severity, and a recommended fix tied to Wazuh's documentation. Under CIS Controls Safeguard 18.3, findings should be remediated on a timeline set by each finding's impact and priority, so the client assigns owners and due dates for each item. The report is written so that the client's auditors or customers can trace each control to its evidence. The step closes when the client has accepted the report and the remediation owners are named.
Retest fixed findings and confirm closure
After the client reports fixes, the reviewer repeats the original test for each finding and checks the corrected configuration directly. Findings that are confirmed fixed are marked closed with the date and evidence of the retest. Findings that remain open, or that were fixed in a way that does not address the root cause, are returned to the client with the reason. The retest scope, timing and any additional fee are agreed in writing before the work starts. The step closes when every finding is either confirmed closed or formally accepted as a documented risk by the client.

How the parts of a Wazuh deployment connect and where trust is placed

The core question in a Wazuh review is which component trusts which, and on what basis. A typical deployment has three server-side parts that the review treats as separate trust zones: the Wazuh server, which receives and analyzes agent telemetry, the Wazuh indexer, which stores and searches the alerts, and the Wazuh dashboard, which operators use to investigate them. Agents on endpoints enroll with the server, the server writes events into the indexer over an authenticated connection, and people reach the dashboard and the server and indexer APIs through separate paths. Each of those arrows is a place where trust is granted, so the review maps every one of them before it tests anything.

Agent enrollment is the first boundary. An agent that can enroll with the server becomes a source of trusted data, so the review asks how enrollment is authorized, whether it depends on a shared password, who can issue credentials, and whether an unmanaged host could register itself. On the server side, the review checks the certificate chain that secures the agent connection and the credentials the server uses to write into the indexer. Those service credentials are often the most privileged non-human identities in the stack, because a compromise there can alter or suppress alerts. Confirm, with your own environment and the Wazuh documentation on Wazuh dashboard documentation, which accounts exist, who holds their passwords, and where those secrets are stored.

Operator access is the second boundary, and it is where the security tool most often becomes an entry point. The dashboard, the server API and the indexer API each authenticate users, and their roles determine what a user can change on the server, not just what they can see. The review checks that default credentials were replaced, that the certificates presented by the server, indexer and dashboard chain to a CA the team controls, and that network paths between the three components are limited to the ports and hosts they need. Ask your implementation team to draw this map before the test starts, because the boundaries it shows become the scope boundaries for the assessment.

Which weakness categories the review checks in a Wazuh deployment

This table lists the weakness categories a Wazuh review examines, how each one tends to appear in a real Wazuh stack, and why it matters for the security tool itself. Read each row as a check the review makes against the deployment, not as a finding that already exists. The main takeaway is that a SIEM and XDR platform holds credentials, logs and agent trust, so a weakness here can give an attacker visibility, control or a foothold in the systems it watches.

Weakness category	What it looks like in a Wazuh deployment	Why it matters
Default or unchanged credentials	Built-in Wazuh users still using shipped or predictable passwords on the dashboard, indexer or server API, or service accounts shared across components	Default credentials are widely known, and a SIEM login gives access to alert data, agent inventory and configuration
Missing or weak certificates	Server, indexer and dashboard communicating without properly deployed certificates, self-signed or expired certificates accepted without validation, or inconsistent trust between components	Unverified channels let an attacker on the network intercept or tamper with alerts, credentials and agent traffic
Exposed server or indexer APIs	Wazuh server API or indexer API reachable from networks that do not need them, or published without access controls beyond the default	APIs that manage agents, rules and data are high-value targets, and exposure widens the attack surface of the security stack
Overly broad RBAC roles	Analysts or integrations granted administrative roles, shared accounts used across teams, or custom roles that include more API actions than their job requires	Excess privilege lets a single compromised account change detection rules, hide alerts or alter agent settings
Weak agent enrollment controls	Enrollment without authentication, shared enrollment credentials reused across hosts, or no process to review and remove unknown agents	Enrollment is how endpoints gain trust in the platform, so a rogue agent can feed false data or receive configuration it should not see
Unpatched components	Wazuh server, indexer, dashboard or agents running versions behind the supported release, or components updated inconsistently	Known vulnerabilities in the security platform itself are a direct route into the environment it protects

How the review differs for single-node, clustered and air-gapped deployments

A single-node Wazuh installation typically runs the server, indexer and dashboard on one host, which concentrates trust in one machine. Reviews of this model focus on whether a pilot quietly becomes production without the controls being added, because the defaults that suit a test box often remain in place when real agents and real data arrive.

Default credentials: Confirm that the passwords for Wazuh users were changed during setup and that no sample or test accounts remain, using the password guidance in the Wazuh documentation.
Certificates: Check whether the self-signed certificates generated for the lab were replaced or at least scoped correctly before any agent or analyst outside the team connects.
Exposure: Verify that the dashboard and API ports are not reachable from networks beyond the pilot group, since a single host often has broader firewall rules than intended.
Data and backups: Ask who holds the indexer data and how it is backed up, because a pilot usually has no documented recovery path.
Promotion gate: Confirm that a written list of controls must be closed before the node takes live endpoint telemetry.

Before sign-off, ask the team to show the lab-to-production change record, including each default that was reset and each certificate that was reissued.

Which compliance frameworks expect this evidence

Does CIS Controls v8.1 require penetration testing of a SIEM like Wazuh?

CIS Controls v8.1 Safeguard 16.13 asks for application penetration testing, which covers software your organization builds or configures and exposes to users or other systems. A Wazuh deployment, with its dashboard, server API and indexer API, is an internet-adjacent or internally reachable application, so a buyer should confirm with their assessor whether it falls inside their Control 16 scope. Most teams include the management interfaces in the test because a compromised security tool can hide activity or pivot into monitored systems. The control asks for testing, not a particular tool or result, so the scope should be written down and agreed before work starts.

What does CIS Safeguard 18.3 expect after a Wazuh penetration test?

Safeguard 18.3 expects penetration test findings to be remediated, with a timeline set by each finding's impact and priority. An auditor will look for a findings register, a severity or priority rating for each item, a documented owner, and dated evidence that fixes were made and retested. For a Wazuh deployment, a finding such as a default credential left in place would usually rank higher than a cosmetic dashboard issue, and the timeline should reflect that. Ask your assessor which timeline they expect you to document, because the control leaves the timing to your own risk decisions.

Which evidence do auditors expect for Wazuh default passwords and certificates?

Auditors usually expect proof that default credentials were changed and that transport encryption is configured for the server, indexer and dashboard. Wazuh's documentation covers changing the default passwords of its users and deploying certificates for these components, so those are the configuration points to evidence. A reasonable evidence set includes a dated record of the password change process, a list of accounts and who holds them, and a configuration review showing certificates are in place. DeployOpen prepares this evidence and tests it, but the audit opinion itself comes from an independent auditor or certification body, not from DeployOpen.

How do customers use a Wazuh security review in vendor due diligence?

Customers reviewing a provider that uses Wazuh to monitor their data want assurance that the monitoring tool cannot be turned against them. They typically ask for a summary of the test scope, the date tested, the categories of weakness checked, and how findings were closed. A summary that names the Wazuh server API, indexer API, dashboard access, RBAC roles and agent enrollment shows that the monitoring layer was examined, not only the systems it watches. Your customer may still require their own questionnaire answers, so the review should be written in a form you can share without exposing exploit detail.

Can DeployOpen issue a compliance certificate for our Wazuh deployment?

No. DeployOpen runs security testing and prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications. Independent auditors and certification bodies make those determinations. What DeployOpen can deliver is a fixed-scope test report, a configuration review against Wazuh's own guidance, and a retest record, which your auditor can review as evidence. Confirm early with your auditor which artifacts they will accept and in what format, since acceptance decisions sit with them.

What should a Wazuh evidence pack contain for an auditor?

An auditor generally wants to trace each claim to a configuration state, a test result and a closure record. A useful pack includes:

The agreed scope and the dates testing took place
Configuration evidence for default credential changes, certificates on the server, indexer and dashboard, and API exposure
RBAC role definitions and a list of who holds each role
Agent enrollment settings and how enrollment is authorized
The findings register with severity, owner, status and retest result

Keep the pack versioned, because an assessor will ask whether evidence reflects the environment at the audit date. Ask the test provider which parts they will supply as signed documents and which they will provide only as working notes.

How does Wazuh testing support an internal control or regulator request?

Regulators and internal audit teams usually ask whether a monitoring system itself is protected, since logs and alerts are relied on for detection and incident evidence. The useful answer is a documented review of access control, encryption, enrollment and API exposure, plus proof that issues were tracked to closure. Your internal audit function will decide which controls map to which requirement, so bring them the scope and findings early. Whether a particular regulator accepts this as sufficient is a question to confirm with that regulator or your legal and compliance team.

Who pays for the evidence work when a framework requires Wazuh testing?

The organization that owns the framework obligation usually pays for the test, the remediation work and the retest, and it also carries the cost of the auditor. Testing is typically a one-time engagement sized to the written scope, while evidence upkeep, log retention checks and periodic retesting recur. Ask any provider to split the quote into testing, remediation support and retesting so you can see which items repeat each year. DeployOpen does not publish a price list, and a quote follows from the written scope.

What the client receives and whether it satisfies an auditor or customer

A Wazuh review produces a set of artifacts that a client can hand to an auditor, a customer security team or an internal risk committee. Each item answers a different question, and none of them is an acceptance decision on its own, because the reader's assessor decides whether the evidence is sufficient for their framework or contract.

Assessment report

The main written report sets out the scope agreed in writing before testing, the Wazuh components reviewed (server, indexer, dashboard and agent enrollment), the method used and each finding with its affected component and configuration state. Ask whether the report states the Wazuh version assessed and the environment boundaries, since an assessor will not accept a finding list without them. Check that out-of-scope items are named, not silently dropped.

Severity ratings with rationale

Each finding should carry a severity rating and a short explanation of how that rating was reached, such as whether default credentials were reachable from an untrusted network or only from an administrative segment. Ask the provider which rating scale it uses and how it maps to your own risk register. Ratings without rationale are hard for an assessor to reconcile with their own criteria.

Configuration evidence

Evidence is the record that a control was checked: the relevant settings of the Wazuh server, indexer and dashboard, certificate details, API exposure, RBAC role mappings and agent enrollment configuration, captured with the date and the reviewer's notes. Ask for evidence in a form your auditor can re-check, and confirm that no secrets appear in the files delivered to you. Redaction rules should be agreed before the work starts.

Remediation plan

The remediation plan assigns an owner, a fix and a target date to each finding, ordered by impact and priority. CIS Controls v8.1 Safeguard 18.3 asks for penetration test findings to be remediated on a timeline set by each finding's impact and priority, so a plan that states that logic is easier to defend. Confirm who writes the timelines: your team sets them, and the provider advises on sequencing.

Retest results

A retest confirms, finding by finding, whether each fix changed the configuration it targeted. Ask whether the retest is included in the fixed-scope quote or priced separately, and whether it is limited to the original findings. A retest report should list each original finding with its status and the evidence used to close it, so it can stand alone in an audit file.

Summary letter for stakeholders

A short summary letter gives executives and customers the scope, dates, the overall outcome and the status of high-severity items without the full technical detail. Customers often ask for this document during vendor due diligence. Confirm whether the letter may name the tested environment and who signs it, and remember that a summary letter does not replace the full report when an auditor asks for evidence.

What your team needs to prepare before the review starts

Before the review starts, the most useful thing your team can do is give the assessor read-only access to the Wazuh server, indexer and dashboard configuration, along with the agent enrollment settings and the RBAC definitions. Read-only access lets the review confirm how the default credentials were changed, which certificates are deployed to each component, how the server API and indexer API are bound and authenticated, and which roles and users exist and what they can reach, without changing anything in a production SIEM. Agree in writing which hosts, configuration files and console views are in scope, and confirm whether the assessor may view the stored security events, since alert data often contains personal or regulated information that needs its own access rules.

Next, provide the architecture documentation and the certificate authority details. The assessor needs a current diagram showing where the Wazuh server, indexer and dashboard run, how agents reach them, which networks and load balancers sit in between, and where any reverse proxy terminates TLS. Also state who operates the certificate authority, how it issues and rotates certificates for each component, and where the private keys are stored. Without this, the review cannot tell whether a certificate gap is a configuration error or a process gap. Name the owner of each component so that questions about configuration, identity and network access reach the right person quickly.

Finally, settle the logistics: a test window or change freeze, named contacts and a clear list of allowed environments. Ask the review provider to state in writing which environments are in scope, for example a staging copy of the deployment or a production instance, and whether any agents on monitored endpoints may be touched. Name one technical contact for the platform, one for the security operations team that reads the alerts, and one escalation contact who can pause the review if a monitored system shows unexpected behavior. Confirm with the operations team that the change freeze covers the agreed window, and that the SOC knows when the review runs, so that assessment activity is not mistaken for a live incident.

What to check when choosing a provider for a Wazuh review

A Wazuh review touches the SIEM, indexer, dashboard, API and agent enrollment, so a provider needs to show Wazuh-specific depth and a method tied to Wazuh's own documentation. The cards below cover what to ask for before commissioning the work, from experience and methodology to the written scope, sample output, named people, data handling and retest terms.

Wazuh-specific experience

Ask which Wazuh components the provider has reviewed in production: the manager, the indexer, the dashboard and the agent fleet. General SIEM experience does not show that a reviewer knows how the server, indexer and dashboard certificates interact, or where the API and indexer credentials are stored. Ask how many of those reviews involved on-premise or air-gapped deployments, since those raise different questions about certificate authorities and update paths. Ask for a description of one past engagement without client names.

Methodology tied to Wazuh documentation

The method should walk through the checks the Wazuh documentation describes: changing default passwords for Wazuh users, deploying certificates for the server, indexer and dashboard, securing the server API and indexer API, and applying role-based access control. Ask the provider to show the checklist it will use and how each item maps to a documented control. A method that is generic web or network testing will miss Wazuh-specific configuration.

Written scope and exclusions

Require a written scope before work starts. It should name the environments in scope, such as production and a staging copy, the Wazuh version, the number of manager nodes and indexer nodes, the agent platforms sampled, and whether active testing against the API is allowed. It should also state what is excluded, for example monitored endpoints outside the sample or the underlying hypervisor. Ambiguity here tends to surface later as disputes over findings or outages during testing.

Sample report and finding format

Ask for a redacted sample report before you commit. Check that each finding states the affected component, the evidence, the impact on the monitoring pipeline and the recommended fix in Wazuh terms. A useful report also separates findings from configuration observations and says which items need a retest. Confirm whether the report is written for your security team, your auditor or both, since those readers need different levels of detail.

Named reviewers and their roles

Ask who will do the work, not only who sells it. Request names or role descriptions for the lead tester and any reviewer who checks the configuration, along with the experience each brings to Wazuh and to Linux server hardening. Confirm whether the same people will attend the closing meeting and answer questions during remediation. Changes in staffing mid-engagement often affect how well findings are understood and retested.

Data handling and retest terms

A Wazuh review can expose security event data, agent inventories and credentials, so ask how the provider will handle that material during testing, where it is stored, how long it is kept and how it is destroyed. Confirm that any credentials used during the review are rotated afterward. Then agree the retest terms in writing: whether one retest of remediated findings is included, the window for it, and whether a final confirmation letter is issued.

What buyers ask before commissioning a Wazuh security review

What drives the cost of a Wazuh security review?

The main cost driver is how much of the Wazuh stack is in scope and how many environments it spans. A review covering a single-node lab differs from one covering a multi-node production cluster with the Wazuh server, indexer, dashboard, agent enrollment paths and API exposure across several networks. Other factors include the number of hosts and agents that must be sampled, whether the review is paired with testing of the surrounding infrastructure, and how much of the configuration is documented. Each quote follows from a written scope, so ask for the components, environments and deliverables to be listed explicitly so that you can compare proposals on the same basis.

How long does a Wazuh deployment security review take?

Duration depends on scope, environment complexity and how quickly your team can provide access and documentation. A review of a single deployment with clear architecture diagrams will generally take less time than one spanning several clusters, custom integrations and a complex network layout. Your team should expect a discovery phase to confirm components, followed by the configuration review and any agreed testing, then reporting. DeployOpen agrees timelines in writing as part of the fixed scope, so ask for the schedule and the points where your team must respond.

What does the review need from our own team?

Expect to provide architecture diagrams, a list of Wazuh server, indexer and dashboard hosts, the version currently running, and details of how agents are enrolled. You will also need named contacts for infrastructure, networking and the SIEM operations team, plus read access to configuration files and an agreed window for any testing that touches live systems. Having your change records and existing certificate inventory ready shortens the discovery phase. Confirm with your provider exactly which access is needed, which accounts will be used, and how credentials are handled during the engagement.

Can our own staff run a Wazuh security review internally?

Internal staff can review many areas, including whether default credentials were changed, whether certificates are deployed for the server, indexer and dashboard, and which users hold which roles. The Wazuh documentation covers these topics, so an experienced team can work through them against the vendor guidance. An independent review adds value where the reviewers did not build the deployment, because it is easier to challenge assumptions about API exposure, agent enrollment and privilege boundaries. Many organizations combine both: internal teams maintain the configuration, and an external review checks it at set points.

Does a Wazuh security review satisfy an auditor?

A security review is evidence for an auditor, but it does not replace one. DeployOpen does not issue audit reports, attestations or certifications, and the independent auditor or certification body decides what evidence is sufficient for a given framework. A review can document configuration, testing scope, findings and remediation, which helps with controls around access management, vulnerability handling and penetration testing. Ask your auditor early which evidence they expect, such as the report format, the dates of testing and proof of remediation, and confirm that the review scope maps to the controls they will assess.

Is retesting included, and how is it priced?

Retesting is normally scoped separately from the initial review because it depends on which findings were fixed and how much verification is needed. Ask for the retest to be defined in the written scope, including which findings it covers, whether it verifies fixes on the live deployment, and what evidence will be returned. CIS Controls v8.1 Safeguard 18.3 asks organizations to remediate penetration test findings within a timeline set by each finding's impact and priority, so agree a retest approach that supports that cycle. DeployOpen does not publish a price list, so request a retest quote from the same written scope.

Which Wazuh areas do buyers most often ask us to confirm first?

Buyers typically ask whether default credentials were replaced, whether TLS is in place for the Wazuh server, indexer and dashboard, whether the server API and indexer API are reachable only from intended networks, and whether role-based access control limits administrators to the duties they need. Confirm with your provider how each area will be checked against the Wazuh documentation for your version, and ask how agent enrollment secrets and certificates will be reviewed. These are the points where a SIEM can become an entry point, so they should appear explicitly in the scope.

How DeployOpen scopes, tests, reports and retests Wazuh deployments

DeployOpen treats a Wazuh review as a fixed-scope engagement that covers the server, indexer, dashboard and agent enrollment as one connected system. We test the deployment in the client's own infrastructure, document each finding against Wazuh's own hardening documentation, and hand over evidence that the client's team and auditors can reuse.

How we scope

We agree the written scope before work starts, naming each Wazuh component, host and network segment in the engagement.
We confirm which Wazuh users, roles and API surfaces are in scope, including default accounts and any custom RBAC roles.
We ask for the deployment architecture, certificate authority arrangements and agent enrollment method so testing matches how the system runs.

How we build

We check that default passwords for Wazuh users were changed and that credential storage follows the client's own secrets process.
We review certificates for the Wazuh server, indexer and dashboard, including trust chains, expiry handling and how agents validate the server.
We test exposure of the server API and indexer API, confirming they are reachable only from intended networks and roles.

How we hand over

We deliver a written report with each finding mapped to the affected component, its impact, and a recommended fix in the client's terms.
We provide a configuration evidence set showing default credential status, certificate details, RBAC role assignments and API access rules.
We walk the client's security and platform teams through findings so remediation owners can act on them without guesswork.

How we support

We agree a retest of the same findings after remediation, so the client can confirm each fix in its own environment.
Ongoing support, upgrades and continuous testing are available as a retainer, which suits deployments that change often.
Confirm with us during scoping how retest timing and any follow-up support will be recorded for your auditor or customer.