How to Configure Wazuh Password Policy

A strong Wazuh password policy is an important part of securing a Wazuh deployment because passwords protect access to the Wazuh Dashboard, Wazuh Indexer, and Wazuh server API.

Weak or reused credentials can allow an attacker to gain access to security alerts, endpoint information, configuration data, and administrative functions.

Wazuh provides native user management for local users, while also supporting external authentication systems such as LDAP, Active Directory, SAML, and other identity providers.

Password requirements therefore depend partly on which authentication architecture your deployment uses.

In this guide, we will examine how Wazuh handles passwords, where password validation is configured, which password-policy controls are available for local users, and when an external identity provider should be used to enforce additional requirements.

What Is a Wazuh Password Policy?

A Wazuh password policy is the collection of rules used to control the strength and management of passwords protecting Wazuh user accounts.

For local Wazuh Indexer users, password validation is provided by the OpenSearch Security layer used by the Wazuh Indexer.

Depending on the configuration, administrators can enforce requirements such as minimum password length, regular-expression-based complexity, or score-based password strength.

This is different from the Wazuh agent enrollment password.

An enrollment password is used to authenticate agents during registration with the Wazuh server and should not be confused with the passwords used by Dashboard or Indexer users.

Related Guide: How to Configure Wazuh Agent Auto-Enrollment

Why Password Policies Matter for Wazuh Deployments

Wazuh is a security monitoring platform, so compromising a privileged account can provide an attacker with access to highly sensitive security information.

A compromised Dashboard account may expose:

• Security alerts and event data
• Endpoint and agent information
• Vulnerability information
• File integrity monitoring results
• Security configuration
• Wazuh users and roles
• Detection rules and decoders
• Administrative functionality

The risk becomes greater when users have excessive privileges.

Password controls should therefore be implemented together with least-privilege access controls.

Related Guide: How to Configure Wazuh RBAC

Wazuh RBAC determines what an authenticated user can do, while authentication determines whether the user can establish an authenticated session in the first place.

These are complementary security controls rather than substitutes for one another.

How Wazuh Password Policies Protect the Wazuh Dashboard and API

The Wazuh Dashboard relies on authenticated Wazuh users and communicates with the Wazuh Indexer and Wazuh server API.

The Wazuh Indexer maintains internal users, including accounts used by administrators and by Wazuh components.

For example, Wazuh documents the admin Indexer account as the default administrator account and kibanaserver as an account used for Dashboard-to-Indexer communication.

Wazuh also maintains users for the Wazuh server API, including wazuh and wazuh-wui.

Changing default credentials is therefore one of the first security steps administrators should perform after deployment.

Wazuh explicitly recommends changing the default credentials used by Wazuh API and Indexer users.

Overview of the Configuration Process

Configuring a Wazuh password policy generally involves determining which authentication mechanism your deployment uses and then applying password controls at the appropriate layer.

For a deployment using local Wazuh Indexer users, the process typically consists of:

1. Identify the local users that require password protection.
2. Change all default passwords.
3. Determine the minimum password strength required by your organization.
4. Configure password validation in the Wazuh Indexer/OpenSearch Security layer.
5. Apply the updated security configuration.
6. Test the policy by creating or modifying an internal user.
7. Verify that weak passwords are rejected.
8. Review Wazuh roles and permissions separately.
9. Monitor authentication and security events.
10. Document password-management procedures.

For environments using LDAP, Active Directory, SAML, OIDC, Okta, Microsoft Entra ID, Google Workspace, Keycloak, or another identity provider, password requirements are generally managed by that external authentication system rather than by Wazuh itself.

Related Guides:

• How to Configure Wazuh LDAP Authentication
• How to Configure Wazuh SSO
• How to Configure Wazuh SAML Authentication
• How to Configure Wazuh OIDC

Wazuh Password Policy Best Practices

A secure Wazuh password strategy should go beyond simply requiring uppercase letters, numbers, and symbols.

Recommended practices include:

• Change all default Wazuh credentials immediately after installation.
• Use long, unique passwords for administrative accounts.
• Prefer randomly generated passwords stored in a password manager.
• Avoid shared administrative accounts where possible.
• Apply least-privilege RBAC roles.
• Use centralized authentication for larger organizations.
• Enable MFA through the organization’s identity provider where supported.
• Monitor authentication and audit events.
• Protect credentials used by Wazuh components such as Filebeat and the Dashboard.
• Rotate credentials when there is a known compromise or organizational requirement.
• Avoid embedding credentials directly in scripts or publicly accessible configuration files.
• Test password-policy changes before applying them to production users.

Modern password guidance increasingly emphasizes password length and resistance to commonly used or compromised passwords rather than relying exclusively on arbitrary character-composition rules.

NIST’s current Digital Identity Guidelines, for example, require single-factor passwords to be at least 15 characters and recommend blocklisting commonly used or compromised passwords rather than imposing additional composition rules.

This does not mean every Wazuh deployment must immediately adopt NIST’s exact requirements.

Instead, organizations should use their regulatory requirements, threat model, authentication architecture, and MFA strategy to determine appropriate controls.

Understanding Wazuh Password Policy

Before changing password settings, it is important to understand which Wazuh component actually handles each part of authentication.

A Wazuh deployment consists of several security-sensitive components, including the Wazuh Dashboard, Wazuh server API, and Wazuh Indexer.

Password-based authentication can therefore involve more than one user database or authentication mechanism.

Wazuh’s user administration functionality covers password management, internal users and RBAC, SSO, and LDAP/Active Directory integration.

What Is the Wazuh Password Policy?

The term Wazuh password policy can refer broadly to the rules governing passwords used to access Wazuh.

However, it is important not to assume that all password controls are implemented by one Wazuh configuration file.

For local Wazuh Indexer users, password validation is handled by the OpenSearch Security plugin.

Current OpenSearch Security documentation provides settings for password minimum length, regular-expression validation, and score-based password-strength validation.

For example, an administrator can configure a regular expression that requires a password to contain uppercase and lowercase letters, a number, a special character, and a minimum number of characters.

OpenSearch also provides score-based validation using zxcvbn, which evaluates password strength rather than simply checking whether individual character classes are present.

This distinction is particularly important when documenting Wazuh password policies because password complexity validation and enterprise password lifecycle management are not necessarily the same thing.

Definition of a Password Policy in Wazuh

A password policy can be thought of as a set of authentication requirements that determine whether a password is acceptable and how credentials should be managed.

In a Wazuh environment, these requirements may include:

• Minimum password length
• Password complexity
• Password strength
• Password reuse controls
• Password expiration
• Account lockout
• Failed-login handling
• Credential rotation
• MFA requirements

However, not all of these controls are native Wazuh Indexer password settings.

For example, OpenSearch Security exposes password validation controls for internal users, while enterprise requirements such as password expiration or MFA may be better handled by an external identity provider.

This means administrators should map each requirement to the component responsible for enforcing it instead of assuming that every requirement can be configured in Wazuh.

Components That Make Up a Wazuh Password Policy

A Wazuh password-management architecture can contain several layers.

Wazuh Indexer internal users

These users are stored in the Indexer’s internal security database and can authenticate directly against the Wazuh Indexer security layer.

Wazuh server API users

The Wazuh server API has its own users and credentials. Wazuh provides the wazuh-passwords-tool.sh utility for managing passwords for Wazuh Indexer users and Wazuh server API users.

Wazuh Dashboard

The Dashboard provides the web interface through which administrators and analysts authenticate and interact with Wazuh.

Wazuh RBAC

RBAC controls the permissions assigned to authenticated users. A successful login does not automatically grant administrative access; the user’s roles and policies determine what resources and operations are available.

External identity providers

Organizations can use LDAP, Active Directory, SAML, OIDC, or other supported identity providers for centralized authentication. These systems can provide password lifecycle controls that are not part of the native Wazuh internal-user model.

Wazuh Indexer Security

The Indexer Security layer provides authentication, authorization, password validation, TLS, and other security functionality around the Indexer.

Relationship Between Wazuh Users, Roles, and Passwords

Users, passwords, and roles represent different security concepts.

A user identifies the person or service attempting to access Wazuh.

A password is one possible authentication credential used to establish the user’s identity.

A role determines what an authenticated user is permitted to do.

For example, an analyst might authenticate using an internal Wazuh user and receive a read-only role. An administrator could authenticate through a separate account and receive administrative permissions.

Wazuh RBAC allows administrators to create internal users and map them to Wazuh roles and policies.

This separation follows the principle of least privilege: authentication establishes identity, while authorization determines access.

Related Guide: How to Configure Wazuh RBAC

How Wazuh Handles User Authentication

Wazuh can authenticate users through its native internal-user system or through external authentication systems.

The native model uses Wazuh Indexer internal users.

External authentication can integrate Wazuh with identity providers and directory services such as LDAP and Active Directory.

Wazuh also documents integrations with providers including Okta, Microsoft Entra ID, Google Workspace, Keycloak, and others.

The authentication architecture therefore depends on how the Wazuh deployment was configured.

Wazuh Dashboard Authentication

The Wazuh Dashboard is the primary web interface used by security analysts and administrators.

When a user signs in with a local account, authentication involves the Wazuh Indexer security layer and its internal user database.

Wazuh documents internal users as accounts that can be created and mapped to appropriate Indexer and Wazuh roles.

The Dashboard itself should therefore not be treated as an independent password-policy engine.

For local users, the relevant password validation controls belong to the underlying security system.

Related Guide: Wazuh Dashboard Not Loading? Complete Troubleshooting Guide

Wazuh API Authentication

The Wazuh server API uses its own authentication mechanism and user accounts.

Wazuh documents the wazuh account as the default Wazuh server API administrator and wazuh-wui as an account used for Dashboard-to-API communication.

These credentials should be managed separately from ordinary analyst accounts and protected carefully because API credentials can provide significant administrative capabilities.

Wazuh provides the wazuh-passwords-tool.sh utility for changing passwords associated with Wazuh users.

Related Guide: Wazuh API Authentication Failed? Causes and Solutions

Wazuh Indexer Security and Authentication

The Wazuh Indexer uses the OpenSearch Security plugin to provide authentication and authorization capabilities.

For internal users, password requirements can be configured through OpenSearch Security settings.

Current documentation supports regular-expression password validation, minimum password length, and score-based password-strength validation.

For example, the following OpenSearch Security settings can enforce a minimum length and password-strength threshold:

plugins.security.restapi.password_min_length: 12
plugins.security.restapi.password_score_based_validation_strength: very_strong

The exact settings and supported behavior should always be checked against the OpenSearch Security version bundled with the Wazuh release being deployed.

Do not blindly copy OpenSearch configuration from an unrelated version into production.

Wazuh packages and configures specific component versions as part of its release architecture.

Local Wazuh Users Versus External Identity Providers

There are two major approaches to user authentication.

Local users

Local users are maintained within the Wazuh Indexer security system.

This approach is straightforward for small environments and can be useful for service accounts, break-glass accounts, and environments that do not have a centralized identity platform.

External identity providers

External authentication allows an organization to centralize authentication and enforce enterprise-wide controls.

This can be particularly useful when the organization requires:

• Centralized password policies
• MFA
• Conditional access
• Account lifecycle management
• Centralized password expiration
• Enterprise password history
• Centralized account lockout
• Automated user provisioning and deprovisioning
• Single sign-on

Wazuh supports external authentication and identity-management integrations, including SSO and LDAP/Active Directory.

Related Guides:

• How to Integrate Wazuh with Okta
• How to Integrate Wazuh with Azure AD
• How to Integrate Wazuh with Google Workspace
• How to Integrate Keycloak with Wazuh

Authentication Flow Between Wazuh Components

A simplified local-user authentication flow looks like this:

1. A user opens the Wazuh Dashboard.
2. The user submits their username and password.
3. The Dashboard authentication process communicates with the Wazuh security infrastructure.
4. The Indexer Security layer validates local credentials when the account is an internal Indexer user.
5. The user’s roles and mappings determine the permissions granted after authentication.
6. The Dashboard uses the resulting authenticated context when accessing Wazuh resources.
7. Requests to the Wazuh server API are authenticated separately according to the API’s authentication mechanism.
8. Wazuh RBAC determines which API operations and resources the authenticated user can access.

The important point is that authentication and authorization occur at different layers.

A password policy controls the quality and acceptance of credentials, while RBAC controls what an authenticated identity can access.

Wazuh Password Policy Components

A practical Wazuh password policy should be evaluated component by component.

Some controls can be implemented directly for local Indexer users, while others are better handled by an external identity provider.

Minimum Password Length

Minimum password length is one of the most important password-policy controls.

OpenSearch Security provides the plugins.security.restapi.password_min_length setting for local users.

Current OpenSearch documentation identifies 8 characters as the default minimum for this setting and allows administrators to configure a higher threshold.

For example:

plugins.security.restapi.password_min_length: 12

Organizations with stronger security requirements may choose a substantially longer minimum.

For human-generated passwords, longer passwords are generally preferable to short passwords that merely satisfy complex character requirements.

NIST’s current guidance requires single-factor passwords to be at least 15 characters and recommends checking passwords against lists of commonly used or compromised values.

Therefore, a Wazuh deployment should avoid treating eight characters as an inherently strong password requirement simply because it is the documented OpenSearch default.

Password Complexity Requirements

Password complexity determines which characteristics a password must contain.

OpenSearch Security supports regular-expression validation for internal users. For example, a policy can require:

• Uppercase letters
• Lowercase letters
• Numbers
• Special characters
• A minimum length

A typical configuration can look like:

plugins.security.restapi.password_validation_regex: '(?=.*[A-Z])(?=.*[^a-zA-Z\d])(?=.*[0-9])(?=.*[a-z]).{12,}'
plugins.security.restapi.password_validation_error_message: "Password must be at least 12 characters and contain uppercase, lowercase, numeric, and special characters."

OpenSearch also supports score-based password validation using zxcvbn. This approach evaluates password strength rather than simply checking whether individual character categories are present.

This can be useful because a password such as Password123! technically satisfies many traditional complexity rules while remaining highly predictable.

Important: NIST’s current guidance recommends against imposing additional composition rules on passwords and instead emphasizes length and blocklisting commonly used or compromised passwords.

Organizations should therefore choose between traditional regex complexity rules and modern strength-based validation based on their security standards and compatibility requirements.

Password History

Password history prevents users from repeatedly cycling through the same small set of passwords.

This control is particularly useful when an organization requires periodic password changes.

Without password-history enforcement, a user could potentially change a password and then immediately return to a previously used credential.

However, administrators should distinguish between Wazuh’s native local-user password validation and password-history functionality provided by an enterprise identity provider.

The current Wazuh documentation focuses its native password-management functionality on changing passwords for Wazuh Indexer and Wazuh server API users, while OpenSearch Security’s documented password-validation settings focus on length, regex validation, and strength scoring.

If password history is an organizational requirement, an external identity provider or directory service is generally the more appropriate place to enforce it.

Related Guide: How to Configure Wazuh LDAP Authentication

Password Expiration

Password expiration requires credentials to become invalid after a defined period.

For example, an organization might establish a requirement that privileged credentials must be reviewed or rotated every 90 days.

Password expiration should not be confused with the ability to manually change a Wazuh password.

Wazuh provides tools for changing credentials, but that does not mean Wazuh’s local-user system should be treated as a complete enterprise password-lifecycle management platform.

If automatic password expiration is required, it is generally preferable to enforce that requirement through the organization’s identity provider or directory service.

This also centralizes password lifecycle management across Wazuh and other enterprise applications.

Account Lockout

Account lockout protects against repeated authentication attempts by temporarily disabling or restricting an account after a defined number of failures.

For example, an enterprise identity provider may lock an account after five or ten unsuccessful authentication attempts.

Administrators should not assume that a native Wazuh Indexer password-validation regex or minimum-length setting provides account lockout.

Those settings address password quality rather than failed-login account state.

If account lockout is a mandatory organizational control, configure it at the authentication provider responsible for the Wazuh user’s identity.

This is one reason centralized authentication becomes increasingly valuable as Wazuh deployments grow.

Failed Authentication Attempts

Failed authentication attempts should be monitored because repeated failures can indicate:

• Password guessing
• Credential stuffing
• Brute-force activity
• Misconfigured applications
• Expired credentials
• Incorrect service-account passwords
• Automated attacks against the Dashboard or API

Wazuh can also be used to monitor authentication-related events and generate alerts when suspicious behavior occurs.

Related Guide: How to Configure Wazuh Audit Logs

Organizations should distinguish between detecting failed authentication attempts and blocking repeated attempts.

Detection belongs to monitoring and security analytics, whereas blocking or account lockout belongs to the authentication layer.

Password Reuse Restrictions

Password reuse restrictions prevent users from selecting credentials that they have previously used.

This control is particularly valuable if passwords are periodically rotated. Otherwise, forced rotation can encourage users to cycle through predictable variations of old passwords.

As with password history and expiration, administrators should verify whether the authentication backend actually supports password-reuse enforcement.

For local Wazuh Indexer users, the documented OpenSearch Security password-policy mechanisms include minimum length, regex validation, and score-based strength validation; they should not be presented as equivalent to a full enterprise password-history and reuse system.

When password-history and reuse controls are mandatory, implementing them in LDAP, Active Directory, or an enterprise identity provider provides a more centralized and consistent enforcement point.

Related Guide: How to Configure Wazuh SSO

A centralized identity architecture also allows the same password-history, expiration, lockout, and MFA controls to apply across Wazuh and the rest of the organization’s applications.

Prerequisites for Configuring a Wazuh Password Policy

Before configuring a Wazuh password policy, identify which Wazuh component is responsible for authenticating each user and determine whether the policy will apply to local Wazuh Indexer users or users authenticated through an external identity provider.

This distinction matters because Wazuh has multiple authentication paths.

Local Wazuh Indexer users are managed through the OpenSearch Security layer, while LDAP, Active Directory, SAML, OIDC, and other external authentication mechanisms can move password-policy enforcement to the identity provider.

Supported Wazuh Version

First, identify the Wazuh version running in your environment.

Wazuh’s security configuration and password-management behavior can change between releases, particularly when the bundled Wazuh Indexer and OpenSearch Security components change.

The current Wazuh documentation should therefore be used as the primary reference when modifying security configuration files.

Run the following command on a Wazuh server to identify the installed version:

/var/ossec/bin/wazuh-control info

You can also check the installed Wazuh package:

dpkg -l | grep wazuh-manager

On RPM-based systems:

rpm -qa | grep wazuh-manager

For production systems, record the versions of the Wazuh manager, Wazuh Indexer, and Wazuh Dashboard before making security changes.

If you are following configuration examples from another Wazuh release, verify that the referenced file paths, parameters, and commands still apply to your installed version.

Administrative Access

You need administrative access to the components whose authentication configuration you intend to modify.

For a local Wazuh Indexer password policy, this normally means having sufficient privileges to:

• Access the Wazuh Indexer host.
• Read the Indexer security configuration.
• Modify the relevant security settings.
• Apply the updated security configuration.
• Restart services when required.
• Authenticate as an appropriate Indexer administrator.
• Test the resulting authentication behavior.

On Linux installations, configuration files under /etc/wazuh-indexer/ are normally protected and require root or equivalent privileges.

You should also have Wazuh Dashboard administrative access if you intend to review internal users, roles, or authentication settings through the Dashboard.

Do not use the admin account for routine analyst activity simply because it is convenient.

Administrative credentials should be reserved for administrative operations.

Access to Wazuh Indexer Security Configuration

Local Wazuh Indexer users are managed through the OpenSearch Security configuration.

The primary security configuration directory is:

/etc/wazuh-indexer/opensearch-security/

Wazuh documents several important files in this directory, including:

config.yml
internal_users.yml
roles.yml
roles_mapping.yml
action_groups.yml
tenants.yml
nodes_dn.yml
allowlist.yml
audit.yml

internal_users.yml contains internal user definitions, while config.yml controls authentication and authorization configuration.

Roles and role mappings are maintained separately.

Do not assume that editing a YAML file automatically changes the active security configuration.

OpenSearch Security maintains an effective security configuration in its security index, so administrators must use the appropriate security administration procedure to apply changes.

This is especially important in clustered environments, where an inconsistent security configuration can produce authentication failures or configuration drift.

Identifying the Authentication Backend

Before changing a password policy, determine how your Wazuh users authenticate.

There are two broad possibilities.

Local authentication

Users are maintained as Wazuh Indexer internal users. Their passwords are stored and validated through the Indexer security subsystem.

External authentication

Users authenticate through an external identity provider or directory service, such as:

• LDAP
• Active Directory
• SAML
• OIDC
• Okta
• Microsoft Entra ID
• Google Workspace
• Keycloak

If users authenticate through an external provider, changing a local Wazuh Indexer password policy may not affect those users.

For example, if an organization requires:

• 15-character minimum passwords
• Password history
• Password expiration
• Account lockout
• MFA
• Compromised-password detection

those controls may be better enforced centrally by the organization’s identity provider.

Related Guides:

• How to Configure Wazuh LDAP Authentication
• How to Configure Wazuh SSO
• How to Configure Wazuh SAML Authentication
• How to Configure Wazuh OIDC

Backing Up Existing Security Configuration

Always back up the existing Wazuh Indexer security configuration before changing authentication settings.

At minimum, preserve copies of:

/etc/wazuh-indexer/opensearch-security/config.yml
/etc/wazuh-indexer/opensearch-security/internal_users.yml
/etc/wazuh-indexer/opensearch-security/roles.yml
/etc/wazuh-indexer/opensearch-security/roles_mapping.yml

For a more complete backup, preserve the entire security configuration directory:

sudo cp -a /etc/wazuh-indexer/opensearch-security \
  /root/wazuh-opensearch-security-backup

However, a file-level backup alone may not represent the complete active configuration.

Wazuh’s documentation specifically notes that the files on disk may differ from the effective configuration stored in the OpenSearch Security index.

For production changes, export the active security configuration using the appropriate security administration procedure before making significant modifications.

This is particularly important before modifying authentication providers, internal users, roles, or role mappings.

Understanding the Impact on Existing Users

Password-policy changes can immediately affect existing users.

For example, increasing a minimum password requirement may mean that newly created or changed passwords must satisfy the new policy.

Changing credentials for service accounts can also break communication between Wazuh components.

Wazuh documents several important internal accounts:

• admin — Wazuh Indexer administrator
• kibanaserver — Dashboard-to-Indexer communication
• wazuh — Wazuh server API administrator
• wazuh-wui — Dashboard-to-Wazuh API communication

Changing these passwords may require updating credentials in other Wazuh components.

For example, changing the admin password can require updates to Filebeat and the Wazuh server, while changing the kibanaserver password requires updating the Dashboard configuration.

Related Guide: Wazuh Filebeat: A Step-by-Step Setup Guide

Plan password-policy changes during a maintenance window when modifying service credentials or security configuration across multiple nodes.

Check the Current Wazuh Password Policy

Before introducing new password requirements, determine what is currently enforced.

Do not begin by editing opensearch.yml, internal_users.yml, or another configuration file without first establishing the existing authentication architecture.

Identify the Active Password Policy Configuration

For local Wazuh Indexer users, inspect the Wazuh Indexer security configuration and identify the password-validation settings supported by your installed version.

The relevant configuration can include controls for password length and password validation.

Current OpenSearch Security documentation provides password-validation settings including minimum password length, regular-expression validation, and score-based password-strength validation.

For example, inspect the Indexer configuration:

sudo grep -RniE \
'password_min_length|password_validation_regex|password_score_based_validation' \
/etc/wazuh-indexer/ 2>/dev/null

If no matching settings are present, do not automatically conclude that there is no password requirement.

Wazuh’s password-management tooling itself imposes requirements on passwords generated or supplied through that tool.

For example, current Wazuh documentation states that passwords supplied to the Wazuh passwords tool must be between 8 and 64 characters and include uppercase, lowercase, numeric, and supported special characters.

Inspect Wazuh Security Settings

Review the Indexer security configuration before modifying it:

sudo ls -la /etc/wazuh-indexer/opensearch-security/

Then inspect the relevant configuration:

sudo less /etc/wazuh-indexer/opensearch-security/config.yml

For internal users:

sudo less /etc/wazuh-indexer/opensearch-security/internal_users.yml

Be careful when sharing this output with other people. internal_users.yml contains password hashes and should be treated as sensitive security configuration even though it does not contain plaintext passwords.

Also verify whether the deployment contains multiple Wazuh Indexer nodes.

In a multi-node cluster, security configuration changes need to be handled consistently across the cluster.

Related Guide: How to Build a Wazuh Indexer Cluster

Review Existing User Configuration

Review the existing internal users and determine which accounts are human users and which are service accounts.

For example:

sudo grep -n '^[a-zA-Z0-9_-]\+:' \
/etc/wazuh-indexer/opensearch-security/internal_users.yml

Do not modify service accounts simply because they appear in the internal-user database.

Accounts such as kibanaserver and other component-specific users exist to facilitate communication between Wazuh components.

Their credentials must remain synchronized with the applications that use them.

A password-policy implementation should therefore distinguish between:

Human accounts

Used by analysts, incident responders, security engineers, and administrators.

Service accounts

Used for communication between Wazuh components or integrations.

Human accounts can generally be subject to organizational password requirements, while service-account credential management needs to account for application compatibility and automated rotation.

Verify Current Password Requirements

Test the current behavior before changing the policy.

For example, create or modify a test user rather than testing destructive changes against the production administrator account.

A useful test matrix includes:

Wazuh’s own password-management tool currently requires a password to contain uppercase and lowercase characters, a number, and one of the supported special characters.

This provides a useful baseline when determining how your existing deployment behaves.

Test the Existing Authentication Behavior

Before changing the policy, verify that a known test account can successfully authenticate.

You can test through the Wazuh Dashboard or directly against the Wazuh Indexer API.

For example:

curl -k -u 'testuser:<PASSWORD>' \
  https://<WAZUH_INDEXER>:9200/

A successful response demonstrates that the credentials are accepted by the Indexer.

A failed response should then be correlated with the Indexer security logs rather than immediately interpreted as a password-policy failure.

This baseline is valuable because it allows you to distinguish a password-policy change from unrelated authentication problems such as:

• Invalid credentials
• Incorrect certificates
• Authentication-provider configuration errors
• Role-mapping problems
• Network connectivity failures
• Dashboard configuration problems

Related Guide: Wazuh API Authentication Failed? Causes and Solutions

Configure the Wazuh Password Policy

Once the existing authentication architecture has been documented, configure the password controls that are actually supported by the authentication backend.

For local Wazuh Indexer users, password-strength requirements are enforced through the Wazuh Indexer/OpenSearch Security layer.

Wazuh’s password-management tooling also provides its own password requirements when changing internal-user credentials.

Configure Minimum Password Length

A minimum password length prevents users from selecting trivially short credentials.

For local Wazuh Indexer authentication, configure the supported password minimum-length setting for your installed Wazuh/OpenSearch Security version.

For example, a policy might establish a 12-character minimum:

plugins.security.restapi.password_min_length: 12

The exact location and supported configuration mechanism should be verified against the OpenSearch Security version bundled with your Wazuh release.

The goal is to ensure that a password such as:

Wazuh123!

cannot satisfy the policy merely because it contains several character classes.

A longer password or passphrase provides substantially more room for resisting guessing attacks.

Set a Minimum Password Length

Choose a minimum based on your organization’s security requirements rather than simply copying a vendor default.

For an enterprise deployment, a practical policy might require at least 12 or more characters for local human accounts, while organizations following stricter authentication standards may choose a higher threshold.

NIST’s current Digital Identity Guidelines use 15 characters as the minimum for single-factor passwords and recommend checking passwords against commonly used or compromised-password blocklists.

This reflects the broader shift toward longer passwords rather than relying exclusively on complex character combinations.

Choose an Appropriate Length for Enterprise Environments

Enterprise environments should consider:

• Regulatory requirements
• Risk level
• Whether MFA is enabled
• Whether passwords are randomly generated
• Whether passwords are stored in a password manager
• Whether authentication is centralized
• Whether privileged accounts have stronger requirements

For administrative Wazuh accounts, randomly generated credentials stored in a secure password manager are preferable to memorable passwords constructed manually.

Test the New Requirement

After applying the minimum-length configuration, test both sides of the requirement.

For example:

ShortPassword1!

should fail if it is below the configured minimum.

A sufficiently long password satisfying the remaining requirements should succeed.

Do not use a production administrator account as the test account.

Configure Password Complexity

Password complexity determines which characteristics a local password must contain.

Depending on the Wazuh Indexer/OpenSearch Security configuration, complexity can be implemented using regular-expression validation or password-strength scoring.

Require Uppercase and Lowercase Characters

A traditional complexity policy can require at least one uppercase and one lowercase character.

For example:

WazuhSecurity2026!

contains both character cases.

However, complexity requirements should not be considered a substitute for sufficient password length.

Require Numbers

A complexity expression can require at least one numeric character.

For example:

WazuhSecurity2026!

contains the numeric sequence 2026.

Avoid rules that encourage predictable substitutions such as:

P@ssw0rd

These passwords satisfy many traditional complexity rules while remaining highly predictable.

Require Special Characters

A policy can require a special character such as:

!
@
#
$
%

The exact set of characters accepted should be tested against the Wazuh version and password-management mechanism being used.

Wazuh’s current password-management tool documentation specifies a particular set of supported symbols for passwords supplied to the tool, so administrators should not assume that every punctuation character will behave identically across every Wazuh authentication component.

Configure Complexity Requirements Supported by the Wazuh Authentication Backend

For local Indexer users, complexity can be implemented using password-validation settings supported by the OpenSearch Security layer.

A traditional regular-expression approach can enforce several character classes simultaneously.

For example, a conceptual policy could require:

plugins.security.restapi.password_validation_regex: '(?=.*[A-Z])(?=.*[a-z])(?=.*[0-9])(?=.*[^a-zA-Z0-9]).{12,}'

This requires:

• At least one uppercase character
• At least one lowercase character
• At least one number
• At least one non-alphanumeric character
• At least 12 characters

A password-validation error message can also be configured so that users receive a meaningful explanation when a password fails validation.

However, consider using score-based password validation where supported rather than relying exclusively on character-class rules.

A password such as Winter2026! may satisfy traditional complexity requirements while remaining easy to guess.

Configure Password Expiration

Password expiration is frequently included in enterprise password policies, but it is important to distinguish it from password-strength validation.

A minimum-length or complexity rule determines whether a password is acceptable.

Password expiration determines how long that password remains valid.

The current Wazuh password-management documentation focuses on changing and generating passwords for Wazuh Indexer and Wazuh server API users; it does not document a native local-user maximum-password-age setting equivalent to enterprise directory services.

Therefore, do not invent an opensearch.yml password-expiration parameter and present it as a native Wazuh feature.

Set Password Maximum Age

If password maximum age is an organizational requirement, implement it through the authentication backend responsible for the user.

For LDAP or Active Directory users, configure password aging in the directory service.

For SSO/OIDC/SAML environments, use the identity provider’s password lifecycle controls.

Local Wazuh Indexer users must verify the capabilities of the exact Wazuh Indexer/OpenSearch Security version before claiming that password expiration is natively supported.

Related Guide: How to Configure Wazuh SSO

Define Password Rotation Requirements

If your organization requires password rotation, define:

• Which accounts require rotation
• How frequently credentials must be reviewed
• Who is responsible for rotation
• How service credentials are rotated
• Where new credentials are stored
• How dependent Wazuh components are updated
• How failed rotations are detected

This is particularly important for service accounts.

Changing an Indexer credential without updating the Wazuh Dashboard, Filebeat, or another dependent component can interrupt communication.

Wazuh explicitly documents these dependencies in its password-management procedures.

Balance Password Expiration With Modern Authentication Practices

Forced periodic password changes should not be treated as a universal security solution.

NIST’s current guidance focuses on password length, compromised-password screening, and stronger authentication rather than requiring arbitrary periodic password changes for every password.

For high-value Wazuh accounts, combining long unique passwords with MFA and centralized identity management can provide stronger protection than forcing users to change passwords on an arbitrary schedule.

Configure Password History

Password history prevents users from immediately reusing previous passwords.

However, password history is another area where administrators should avoid assuming that Wazuh’s local password-strength controls constitute a complete enterprise password-lifecycle system.

Prevent Users From Reusing Previous Passwords

If password history is mandatory, configure it in the identity provider or directory service when Wazuh users authenticate externally.

For example, an Active Directory policy can enforce password-history requirements centrally.

For local Wazuh Indexer users, verify the exact capabilities of the bundled OpenSearch Security version before implementing or documenting a password-history mechanism.

Determine an Appropriate Password History Depth

If your identity provider supports password history, determine how many previous passwords should be remembered.

The appropriate value depends on:

• Organizational policy
• Regulatory requirements
• Password rotation frequency
• Account sensitivity
• MFA availability
• Risk tolerance

Avoid choosing a large history value simply because it appears more secure.

Password history should be aligned with the overall credential-management strategy.

Verify Password Reuse Restrictions

After configuring password history, test the behavior using a dedicated test account:

1. Set an initial password.
2. Change it to a second password.
3. Attempt to reuse the first password.
4. Verify that the authentication backend rejects the reused credential if password history is configured.
5. Confirm that the new valid password works.

For externally authenticated Wazuh users, perform this test against the identity provider rather than the Wazuh Dashboard itself.

Configure Failed Login Attempts

Failed-login controls protect Wazuh accounts against repeated password-guessing attempts.

However, failed-login monitoring and account lockout are different capabilities.

Wazuh can detect and monitor authentication events, while the authentication backend is responsible for determining whether repeated failures result in account lockout or another defensive action.

Set the Maximum Number of Failed Authentication Attempts

If the authentication backend supports failed-attempt thresholds, establish an appropriate maximum.

For example:

5 failed attempts

could trigger a defensive response.

The correct value depends on the organization’s risk tolerance and the likelihood of legitimate users mistyping credentials.

Do not configure an arbitrary threshold without considering the possibility of denial-of-service through intentional account locking.

Configure Account Lockout Behavior

Account lockout should generally be configured in the authentication system that owns the account.

For LDAP or Active Directory users, configure the directory’s lockout policy.

For an identity provider, configure its account-protection controls.

Local Wazuh Indexer users must verify the capabilities of the specific OpenSearch Security version rather than assuming that a password-validation setting provides account lockout.

This distinction prevents a common configuration mistake: confusing password complexity with brute-force protection.

Configure Lockout Duration

Where the authentication backend supports lockout duration, decide whether accounts should:

• Remain locked until manually unlocked
• Automatically unlock after a defined period
• Require administrator intervention
• Use progressive or risk-based authentication controls

Privileged Wazuh administrator accounts may warrant stricter controls than ordinary analyst accounts.

Protect Against Brute-Force Password Attacks

Password policies should be combined with other controls to protect the Wazuh Dashboard and Indexer.

Recommended controls include:

• MFA
• Strong unique passwords
• Account lockout or throttling where supported
• Network restrictions
• Firewall rules
• Reverse-proxy protection
• Monitoring failed authentication events
• Alerting on repeated authentication failures
• Least-privilege RBAC

Wazuh recommends restricting network access to the Indexer API so that it is accessible only from trusted networks.

Related Guide: How to Configure Wazuh Audit Logs

Configure Password Policy for Administrative Accounts

Wazuh administrators require stronger protection because administrative credentials can expose or modify the entire security-monitoring environment.

A compromised administrator account can potentially provide access to Wazuh configuration, security policies, user management, alerts, indexed security data, and other privileged functionality.

Apply Stronger Controls to Wazuh Administrators

Administrative accounts should use credentials that are:

• Long
• Unique
• Randomly generated where practical
• Stored in an enterprise password manager
• Never shared between administrators
• Protected with MFA when using an external identity provider
• Reviewed regularly
• Removed promptly when administrators leave the organization

Avoid using the default admin account as a shared account for multiple administrators.

Instead, create individual administrator identities and assign appropriate administrative roles.

This creates accountability because authentication events can be associated with a specific person rather than a shared credential.

Related Guide: How to Configure Wazuh RBAC

Protect Privileged Accounts

Apply stronger controls to accounts that have access to:

• User management
• RBAC configuration
• Indexer administration
• Wazuh API administration
• Security configuration
• Detection rules
• Audit configuration
• Cluster administration

For external authentication, privileged Wazuh users can inherit enterprise controls such as MFA, conditional access, password screening, and centralized account lifecycle management.

For local accounts, use strong randomly generated credentials and protect them as privileged secrets.

Wazuh’s password-management tool can generate random passwords when a password is not explicitly supplied, which can be useful for service and administrative credentials.

Combine Password Policies With Least-Privilege RBAC

A strong password does not compensate for excessive permissions.

Consider an environment with four groups:

Each group should receive only the permissions required to perform its responsibilities.

This creates multiple defensive layers:

Strong authentication
        ↓
Password / MFA controls
        ↓
Authenticated identity
        ↓
RBAC role mapping
        ↓
Least-privilege permissions
        ↓
Wazuh resources and operations

If an analyst’s password is compromised, RBAC can limit what the attacker can access.

Conversely, if an administrator has excessive permissions, even a strong password provides limited protection against misuse after successful authentication.

Related Guide: Troubleshooting Wazuh RBAC

The strongest Wazuh password-policy implementation therefore combines password strength with centralized identity management, MFA, least-privilege RBAC, network restrictions, and authentication monitoring rather than treating password complexity as a standalone security control.

Configure Wazuh Password Policy With the Wazuh Indexer

The Wazuh Indexer is a critical component of the Wazuh authentication architecture.

For local Indexer users, authentication and authorization are handled through the OpenSearch Security plugin used by the Wazuh Indexer.

This means that configuring a Wazuh password policy for local Indexer users requires understanding the relationship between Wazuh, the Indexer, and the security plugin.

Before changing production authentication settings, verify the exact Wazuh and Wazuh Indexer versions in use.

Configuration parameters and administration procedures can vary between releases.

Understand the Security Plugin

The Wazuh Indexer uses the OpenSearch Security plugin to provide security functionality around authentication, authorization, certificates, users, roles, and other security controls.

The plugin provides the security layer that sits between clients and the Indexer.

For local users, it is responsible for validating credentials and determining whether an authenticated identity has permission to perform a requested operation.

Role of the Wazuh Indexer Security Plugin

The security plugin provides several important capabilities:

• User authentication
• Internal-user management
• Role-based authorization
• Role mappings
• TLS security
• Security configuration
• Authentication backend integration
• Audit capabilities
• Password validation for supported local-user configurations

Password validation is only one part of this security model.

A user can have a valid password and still receive an authorization error because the user’s roles do not permit the requested operation.

How Authentication and Authorization Are Handled

Authentication answers:

Who is this user?

Authorization answers:

What is this authenticated user allowed to do?

For example, an analyst could successfully authenticate with a valid password but receive a 403 Forbidden response when attempting to perform an administrative operation.

The sequence is approximately:

User
  ↓
Authentication
  ↓
Identity established
  ↓
Role mapping
  ↓
Authorization
  ↓
Requested Wazuh resource or operation

This distinction becomes important when troubleshooting Wazuh authentication problems.

A failed login suggests an authentication problem, while a successful login followed by 403 Forbidden generally points toward authorization, role, or permission configuration.

Relationship Between Users, Roles, and Security Policies

The Indexer security architecture separates users from roles.

An internal user has authentication credentials and can be associated with one or more roles.

Roles determine the permissions available to the authenticated identity.

Role mappings then determine which users, backend roles, or groups receive particular roles.

This allows organizations to create different access levels for:

• Security analysts
• Incident responders
• SOC managers
• Wazuh administrators
• Service accounts

Password policy should therefore be considered one layer of the security architecture rather than the entire access-control system.

Modify Security Configuration

Before modifying the Indexer security configuration, back up the existing configuration and verify that you have a tested administrative account available.

Wazuh stores OpenSearch Security configuration files under:

/etc/wazuh-indexer/opensearch-security/

Common files include:

config.yml
internal_users.yml
roles.yml
roles_mapping.yml
action_groups.yml
tenants.yml
nodes_dn.yml

Do not edit every file simply because it exists.

Password-policy changes should be limited to the configuration relevant to the authentication mechanism being used.

Locate the Relevant Security Configuration

Start by examining the security configuration:

sudo ls -la /etc/wazuh-indexer/opensearch-security/

Then inspect the primary security configuration:

sudo less /etc/wazuh-indexer/opensearch-security/config.yml

For internal users:

sudo less /etc/wazuh-indexer/opensearch-security/internal_users.yml

You can search for password-related configuration using:

sudo grep -Rni \
'password_' \
/etc/wazuh-indexer/opensearch-security/ \
/etc/wazuh-indexer/ 2>/dev/null

The exact settings available depend on the OpenSearch Security version bundled with your Wazuh release.

Update Password-Related Settings

For local Wazuh Indexer users, OpenSearch Security supports password validation mechanisms such as minimum length and regular-expression-based validation.

Current OpenSearch documentation also describes score-based password validation.

For example:

plugins.security.restapi.password_min_length: 12

A regex-based policy could require multiple character classes:

plugins.security.restapi.password_validation_regex: '(?=.*[A-Z])(?=.*[a-z])(?=.*[0-9])(?=.*[^a-zA-Z0-9]).{12,}'

You can also provide a custom error message:

plugins.security.restapi.password_validation_error_message: "Password must contain at least 12 characters, including uppercase, lowercase, a number, and a special character."

These settings should only be used after confirming that they are supported by the OpenSearch Security version included with the Wazuh release.

Do not copy configuration parameters from a newer OpenSearch release into an older Wazuh installation without verifying compatibility.

Apply the Configuration Safely

A critical point is that modifying a YAML file does not necessarily mean that the active security configuration has changed.

OpenSearch Security maintains its effective security configuration in the security index.

Configuration files are used to create or update that configuration through the appropriate security administration process.

Therefore, the safe workflow is:

1. Back up the existing configuration.
2. Modify the required setting.
3. Validate the configuration.
4. Apply it using the supported Wazuh/OpenSearch Security administration mechanism.
5. Verify the resulting configuration.
6. Test authentication with a dedicated account.
7. Confirm that existing service accounts continue functioning.

Do not restart every Wazuh component simply because a security configuration has changed.

Restarting services unnecessarily can create avoidable authentication or availability problems.

Verify That the Changes Are Active

After applying the configuration, verify that the expected setting is present in the active security configuration.

Then test a dedicated user.

For example, attempt to set a password that violates the policy.

If the password is rejected, confirm that the error corresponds to the expected password requirement.

Then test a compliant password.

Finally, authenticate with the test account:

curl -k -u 'testuser:<PASSWORD>' \
https://<WAZUH_INDEXER>:9200/

A successful response confirms that the account can authenticate after the configuration change.

Reload or Apply Security Changes

Security configuration changes require careful handling because an error in authentication configuration can prevent legitimate users from accessing the Wazuh environment.

When Configuration Reloads Are Required

Some security configuration changes are applied through the OpenSearch Security administration mechanism rather than by restarting the entire Wazuh Indexer.

Other configuration changes may require a service restart.

The correct procedure depends on the specific setting and the Wazuh/OpenSearch Security version.

Always consult the documentation for the installed version before restarting a production Indexer.

Applying Changes Without Disrupting Authentication

Use a controlled rollout.

For a production cluster:

1. Make a backup.
2. Confirm administrative access.
3. Apply the security change.
4. Monitor Indexer logs.
5. Test a non-privileged account.
6. Test an administrative account.
7. Verify Dashboard access.
8. Verify API access.
9. Confirm service-to-service communication.
10. Monitor for authentication failures.

Keep an existing administrative session open while testing changes.

This provides a recovery path if a new authentication configuration prevents a new login from succeeding.

Confirming Successful Configuration Updates

After applying the policy, verify all relevant authentication paths.

Test:

Wazuh Dashboard
       ↓
Indexer authentication
       ↓
RBAC authorization

Then separately verify:

Wazuh Dashboard
       ↓
Wazuh API
       ↓
API authentication
       ↓
API authorization

Finally, verify service accounts used by Wazuh components.

This prevents a password-policy change from appearing successful simply because one test account can authenticate while an internal Wazuh component has lost access.

Configure Password Policies for Wazuh API Users

Wazuh API authentication should be treated separately from Wazuh Indexer authentication.

The Wazuh server API has its own users and authentication mechanism.

Wazuh provides the wazuh-passwords-tool.sh utility for changing passwords for Wazuh server API users and Wazuh Indexer users.

Understand Wazuh API Authentication

The Wazuh server API exposes management functionality to authenticated clients.

The Dashboard communicates with the API, while administrators and automation systems can also use API endpoints directly.

An API password policy therefore needs to consider both human administrators and non-human service accounts.

Local API Users and Authentication

Wazuh maintains API users separately from Wazuh Indexer internal users.

This means changing an Indexer user’s password does not automatically change the password of a Wazuh API user.

Wazuh documents the wazuh API administrator and wazuh-wui Dashboard-related API account as examples of API credentials that require careful management.

Administrators should therefore inventory API accounts before introducing a password-policy change.

Password Requirements for API Accounts

When changing Wazuh API credentials, use strong, unique passwords.

The Wazuh password-management utility can generate passwords automatically, which is preferable to manually creating predictable credentials for high-privilege service accounts.

For example:

sudo /usr/share/wazuh-indexer/plugins/opensearch-security/tools/wazuh-passwords-tool.sh \
  --api

The exact command-line options should be checked against the installed Wazuh version before execution.

Do not assume that a password policy configured for Wazuh Indexer internal users automatically applies to Wazuh API users.

These are separate authentication systems.

Managing Service and Automation Accounts Securely

Service accounts require special treatment.

A service account might be used by:

• Wazuh Dashboard
• Automation scripts
• SOAR integrations
• Custom applications
• Monitoring systems
• Configuration-management tools

Avoid embedding service-account passwords directly in scripts.

Instead, store credentials in a secrets-management system or another appropriately protected credential store.

Use separate credentials for separate applications whenever practical.

This makes credential rotation and incident response much easier.

Avoiding Unnecessary Use of Administrator Credentials

Do not use the primary Wazuh API administrator account for every automation task.

Instead, create dedicated API identities with only the permissions required by the application.

For example:

Automation application
        ↓
Dedicated API account
        ↓
Restricted permissions
        ↓
Required API endpoints only

This follows the principle of least privilege and reduces the impact of a compromised automation credential.

Related Guide: How to Configure Wazuh RBAC

Testing the Wazuh Password Policy

A password policy is not complete until its behavior has been tested.

Testing should cover both successful and unsuccessful authentication scenarios.

Do not test destructive authentication changes against the only administrator account.

Create a dedicated test account whenever possible.

Test Password Complexity

Start by testing a password that should clearly violate the policy.

For example, if the policy requires 12 characters with multiple character classes:

password

should fail.

Then test a password that satisfies all configured requirements:

V7!qP2#mX9@rL4

The second password should satisfy a traditional 12-character complexity policy.

Do not publish real production passwords in documentation, tickets, screenshots, or log files.

Attempt to Create a Weak Password

Test several failure conditions independently:

short

alllowercasepassword

ALLUPPERCASEPASSWORD

PasswordOnly

Password123

Each should be evaluated against the actual policy rather than assumed to fail.

Attempt to Create a Compliant Password

Create a test password that satisfies every configured requirement.

For example:

T9#vL2!qR8@xM5

Then verify that the authentication backend accepts it.

Verify Enforcement

The test is successful only if the backend rejects non-compliant passwords and accepts compliant ones.

Document the results:

Test Password Expiration

Password expiration requires special consideration because it may not be a native local Wazuh Indexer password-policy feature.

If expiration is configured through LDAP, Active Directory, or an identity provider, perform the test against that authentication backend.

Verify Expiration Behavior

Use a dedicated test account.

Set the account to an appropriate test expiration state and attempt to authenticate.

Verify that the authentication provider produces the expected behavior when the password reaches its maximum age.

Do not intentionally expire a production administrator account as a test.

Test Password Changes

After expiration testing, verify that the user can successfully change the password.

Then test authentication using:

• The old password
• The new password

The old password should no longer authenticate after a successful password change.

Confirm Expected User Notifications or Access Behavior

Depending on the authentication provider, users may receive:

• Password-expiration warnings
• Password-change prompts
• Account-expired notifications
• Access-denied messages

Document this behavior so help-desk and SOC personnel know how to distinguish a password-expiration event from a Wazuh outage.

Test Account Lockout

Account lockout testing should also be performed at the authentication backend that provides the feature.

Generate Failed Login Attempts

Using a dedicated test account, intentionally submit incorrect credentials until the configured threshold is reached.

For example:

Attempt 1 → Incorrect password
Attempt 2 → Incorrect password
Attempt 3 → Incorrect password
...

Do not perform this test against an administrator account that is required for production operations.

Verify Account Lockout

After the configured threshold is reached, attempt authentication using the correct password.

If the account is locked, the correct password should not immediately restore access.

The exact response depends on the authentication backend.

Confirm Account Recovery Behavior

Verify the configured recovery mechanism.

Depending on the environment, recovery may require:

• Waiting for automatic unlock
• Administrator intervention
• Identity-provider self-service recovery
• Password reset
• MFA verification

Document the recovery process as part of the organization’s Wazuh incident-response procedures.

Test Password Reuse Restrictions

Password reuse should be tested separately from password complexity.

Attempt to Reuse an Existing Password

For a test account:

1. Set password A.
2. Change to password B.
3. Attempt to change back to password A.

If password history is configured, the final operation should fail.

Verify Password History Enforcement

Repeat the test using the configured history depth.

For example, if the identity provider remembers the previous five passwords, attempt to reuse a credential within that history window.

This confirms that password history is actually being enforced rather than simply configured.

Remember that password-history functionality may belong to LDAP, Active Directory, or another identity provider rather than the local Wazuh Indexer user system.

Verify Authentication After Configuration

After all policy tests are complete, verify normal Wazuh operation.

Log In Through the Wazuh Dashboard

Use a standard test account to authenticate through the Dashboard.

Verify that:

• Login succeeds.
• The expected Dashboard loads.
• Alerts are visible according to the user’s permissions.
• The correct tenant is available where applicable.
• Restricted functionality remains inaccessible.

Related Guide: How to Set Up Wazuh Multi-Tenancy

Test API Authentication

Test the API independently.

For example:

curl -k -u 'testuser:<PASSWORD>' \
https://<WAZUH_MANAGER>:55000/security/user/authenticate

The exact endpoint and authentication method should be verified against the Wazuh API version in use.

A successful Dashboard login does not prove that API authentication is working because the Dashboard and Wazuh API have separate authentication paths.

Verify Administrator Access

Finally, test an administrator account.

Verify that administrators can still:

• Log in
• Access required Wazuh functionality
• Manage users
• Manage roles
• Perform authorized administrative operations

Do not grant administrator privileges to the test account merely to simplify testing.

Confirm Existing Users Can Authenticate as Expected

Review a representative sample of existing users.

Confirm that:

• Analyst accounts can authenticate.
• Incident responders can authenticate.
• Administrators can authenticate.
• Service accounts remain operational.
• External identity-provider users remain functional.
• RBAC mappings remain intact.

This final verification helps identify unintended side effects from the password-policy change.

Troubleshooting Wazuh Password Policy

Password-policy problems can occur at several layers.

A failed login does not automatically mean the password policy is wrong.

The underlying problem could be the Dashboard, Wazuh Indexer, Wazuh API, authentication provider, TLS configuration, role mapping, or network connectivity.

Password Policy Changes Are Not Taking Effect

If a new password requirement appears to have no effect, work through the configuration layers systematically.

Check Configuration Syntax

Start by checking the YAML syntax.

YAML is sensitive to:

• Indentation
• Quotes
• Special characters
• Colons
• Regular-expression escaping

A malformed value can prevent a configuration from being loaded correctly.

For regex-based password policies, pay particular attention to quoting and special characters.

Verify the Correct Configuration File

Confirm that you modified the configuration belonging to the active Wazuh Indexer installation.

Check:

sudo ls -la /etc/wazuh-indexer/

and:

sudo ls -la /etc/wazuh-indexer/opensearch-security/

Do not modify an unused backup directory and expect the running Indexer to use those settings.

Confirm the Security Configuration Was Applied

Changing a configuration file does not necessarily mean that the active OpenSearch Security configuration has changed.

Verify that the security configuration was successfully loaded using the supported security-administration mechanism for your Wazuh version.

Then perform a controlled authentication test.

Review Wazuh and Indexer Logs

Inspect the Wazuh Indexer logs:

sudo journalctl -u wazuh-indexer

You can also inspect the Indexer log directory:

sudo ls -la /var/log/wazuh-indexer/

Search for authentication and security-related messages:

sudo grep -RiE \
'authentication|password|security|authorization|forbidden|denied' \
/var/log/wazuh-indexer/ 2>/dev/null

Avoid posting complete logs publicly without reviewing them for sensitive information.

Users Cannot Log In After a Policy Change

A policy change that affects multiple users should be treated as a potentially serious authentication incident.

Check Account Lockout Status

If the authentication backend supports account lockout, determine whether the user was locked because of repeated failed authentication attempts.

For external users, check the identity provider or directory service.

For local users, inspect the applicable Indexer security configuration and logs.

Verify Credentials

Confirm that the user is entering the correct username and password.

Check for:

• Incorrect capitalization
• Keyboard-layout problems
• Expired passwords
• Recently rotated credentials
• Cached credentials
• Incorrect service-account secrets

Do not ask users to send passwords through email, chat, tickets, or support systems.

Check Authentication Backend Configuration

If Wazuh uses LDAP, SAML, OIDC, Okta, Microsoft Entra ID, Google Workspace, or another external identity provider, verify that the authentication provider is functioning correctly.

Related Guide:

• How to Integrate Wazuh with Okta
• How to Integrate Wazuh with Azure AD

Review Dashboard and Indexer Logs

If the Dashboard is involved, review Dashboard logs in addition to Indexer logs.

Check for messages involving:

authentication
authorization
401
403
certificate
TLS
security plugin

A 401 Unauthorized response generally indicates that authentication failed, while a 403 Forbidden response generally indicates that authentication succeeded but authorization failed.

Password Complexity Requirements Are Not Enforced

If weak passwords continue to be accepted, determine which authentication system is actually validating the password.

Verify the Active Security Configuration

Confirm that the password-validation settings are present in the active security configuration.

Do not rely exclusively on the contents of the local YAML file.

Check Whether the Setting Is Supported by the Installed Wazuh Version

This is one of the most important troubleshooting steps.

The Wazuh Indexer bundles a specific OpenSearch version and security-plugin implementation.

A configuration parameter documented for a newer OpenSearch release may not be available in your Wazuh release.

Verify:

sudo /var/ossec/bin/wazuh-control info

Then consult the documentation corresponding to that release.

Confirm the Configuration Was Successfully Loaded

Check Indexer logs after applying the configuration.

Look for:

• Configuration parsing errors
• Unknown parameters
• Security-plugin errors
• Authentication-provider errors
• YAML parsing problems

Then repeat the password test using a dedicated account.

Locked Wazuh User Cannot Authenticate

A locked account requires a different troubleshooting approach from a simple incorrect-password error.

Identify Why the Account Was Locked

Determine whether the lock occurred because of:

• Repeated failed authentication
• Identity-provider policy
• Administrator action
• Password expiration
• Security automation
• Another authentication control

Check the relevant authentication provider and security logs.

Unlock or Reset the Account

If the account is controlled by an external identity provider, perform the unlock or reset there.

If it is a local Wazuh Indexer account, use the appropriate Wazuh/OpenSearch Security user-management procedure for the installed version.

Do not modify internal security files manually unless the procedure explicitly requires it.

Verify the Account Can Authenticate Again

After recovery:

1. Authenticate using the new or unlocked credentials.
2. Verify Dashboard access.
3. Confirm the user’s expected roles.
4. Test API access if applicable.
5. Confirm that no additional authentication errors are generated.

If the user can authenticate but receives 403 Forbidden, investigate role mappings rather than resetting the password again.

Related Guide: Troubleshooting Wazuh RBAC

Wazuh Authentication Errors

Authentication problems can originate from several different components.

Common Authentication Errors

Common symptoms include:

Certificate and Security-Plugin Issues

Authentication can fail even when the username and password are correct.

TLS problems can prevent communication between:

• Wazuh Dashboard and Indexer
• Wazuh Dashboard and API
• Filebeat and Indexer
• Administrative clients and Indexer

Look for errors involving:

certificate
SSL
TLS
PKIX
handshake
hostname verification

Related Guide: How to Fix Wazuh Certificate Errors

Permission and Role-Related Errors

If a user successfully authenticates but cannot perform an operation, investigate authorization.

Check:

• User roles
• Role mappings
• Index permissions
• Tenant permissions
• API permissions
• Wazuh RBAC configuration

A password reset will not fix an authorization problem.

For example:

Authentication successful
        ↓
User identified
        ↓
Role mapping
        ↓
Permission check
        ↓
403 Forbidden

This is fundamentally different from:

Username/password submitted
        ↓
Credential validation fails
        ↓
401 Unauthorized

Log Files to Inspect

When troubleshooting authentication, inspect logs from the component that is actually failing.

1. Wazuh Indexer:

sudo journalctl -u wazuh-indexer

2. Wazuh Dashboard:

sudo journalctl -u wazuh-dashboard

3. Wazuh manager/API:

sudo journalctl -u wazuh-manager

You can also inspect the corresponding log directories under:

/var/log/wazuh-indexer/
/var/log/wazuh-dashboard/
/var/ossec/logs/

Search for authentication-related events:

sudo grep -RiE \
'authentication|authorization|401|403|password|certificate|security' \
/var/log/wazuh-indexer/ \
/var/log/wazuh-dashboard/ \
/var/ossec/logs/ 2>/dev/null

When troubleshooting, correlate timestamps across the Dashboard, Indexer, Wazuh manager, and external identity provider.

This makes it much easier to determine whether the failure originates from credential validation, TLS, role mapping, network communication, or the password policy itself.

Wazuh Password Policy Best Practices

A strong Wazuh password policy should not rely on password complexity alone.

Password security is most effective when it is combined with centralized identity management, MFA, least-privilege authorization, secure credential storage, authentication monitoring, and regular access reviews.

The following practices provide a practical baseline for securing Wazuh users and administrators.

Use Long, Unique Passwords

Every Wazuh user should have a unique password that is not reused on other systems.

For privileged Wazuh accounts, randomly generated passwords stored in an enterprise password manager are preferable to manually created credentials.

Long passwords and passphrases provide greater resistance to brute-force and password-guessing attacks than short credentials that merely satisfy character-complexity rules.

NIST’s current Digital Identity Guidelines emphasize password length and screening against commonly used or compromised passwords rather than relying exclusively on arbitrary composition rules.

A practical policy should therefore consider:

• Minimum password length
• Password uniqueness
• Compromised-password screening where supported
• Password-manager usage
• MFA for privileged users

Enforce Strong Password Complexity Where Appropriate

Traditional complexity requirements can require passwords to contain:

• Uppercase characters
• Lowercase characters
• Numbers
• Special characters

Wazuh Indexer/OpenSearch Security supports password validation mechanisms for local users, including minimum-length and regular-expression-based validation, with score-based password validation also available in supported versions.

However, complexity should not become the sole measure of password strength.

For example:

Winter2026!

may satisfy traditional complexity rules while remaining relatively predictable.

A longer, randomly generated password can provide substantially stronger protection.

Protect Privileged Wazuh Accounts

Administrator accounts should receive stronger protection than ordinary analyst accounts.

Privileged accounts can potentially modify:

• Wazuh users
• Roles
• Security configuration
• Detection rules
• Integrations
• Agent configuration
• Indexer configuration
• API settings

Use separate privileged accounts rather than granting administrative privileges to ordinary analyst accounts.

For particularly sensitive environments, combine strong passwords with:

• MFA
• SSO
• Privileged-access management
• Network restrictions
• Session controls
• Authentication monitoring

Related Guide: How to Configure Wazuh RBAC

Use MFA Through an External Identity Provider Where Possible

MFA provides an additional authentication factor beyond the user’s password.

If an attacker obtains a Wazuh user’s password, MFA can prevent the attacker from immediately accessing the environment.

For enterprise deployments, MFA is generally easier to manage through the organization’s identity provider than through individual local Wazuh accounts.

Possible identity-provider integrations include:

• Okta
• Microsoft Entra ID
• Google Workspace
• Keycloak
• Other SAML or OIDC providers

Related Guide: How to Configure Wazuh SSO

Apply Least-Privilege RBAC

Password strength does not determine what an authenticated user can access.

Wazuh RBAC should be used to assign only the permissions required by each user.

For example:

This limits the impact of a compromised account.

Avoid Shared Administrator Accounts

Do not use a single administrator account for an entire SOC.

Instead, create individual administrator identities.

Individual accounts provide:

• Accountability
• Better audit trails
• Easier access reviews
• Easier credential revocation
• More precise RBAC
• Better incident investigation

A shared account makes it difficult to determine which administrator performed a particular action.

Use Dedicated Service Accounts

Service accounts should be separate from human administrator accounts.

For example, use dedicated credentials for:

• Dashboard-to-API communication
• Filebeat
• Automation
• Monitoring integrations
• Custom applications
• SOAR platforms

Assign only the permissions required by each service.

Do not use the primary Wazuh administrator credentials inside automation scripts simply because they already have sufficient permissions.

Related Guide: Wazuh Filebeat: A Step-by-Step Setup Guide

Monitor Failed Authentication Attempts

Repeated authentication failures can indicate:

• Password guessing
• Credential stuffing
• Brute-force attacks
• Stolen credentials
• Misconfigured applications
• Expired passwords
• Broken service credentials

Monitor authentication events and establish alerts for unusual patterns.

For example, a sudden increase in failed Dashboard logins from one source IP could warrant investigation.

Related Guide: How to Configure Wazuh Audit Logs

Regularly Review Wazuh Users and Roles

Perform periodic access reviews.

Review:

• Active users
• Administrative users
• Assigned roles
• Role mappings
• Service accounts
• External identity-provider groups
• Tenant access
• API accounts

The review should answer:

Does this user still need this level of access?

If the answer is no, remove or reduce the permissions.

Remove Inactive Accounts

Inactive accounts increase the attack surface.

When employees leave the organization or change responsibilities, their Wazuh access should be removed or adjusted promptly.

For SSO environments, automated identity lifecycle management can make this process easier by removing access when the corresponding directory or identity-provider account is disabled.

For local Wazuh accounts, administrators need a documented offboarding process.

Securely Manage Password Resets

Password resets should be treated as privileged security operations.

Never send passwords through:

• Email
• Chat messages
• Support tickets
• Plaintext documents
• Unencrypted scripts

Use secure credential-management mechanisms and require appropriate administrator or identity-provider verification before resetting privileged credentials.

After resetting a compromised credential, investigate whether the account was actually compromised and review recent authentication activity.

Back Up Security Configuration Before Making Changes

Always create a backup before modifying:

• Indexer security configuration
• Internal users
• Roles
• Role mappings
• Authentication providers
• SSO configuration

A configuration backup provides a recovery path if an authentication change prevents users from logging in.

For production Wazuh clusters, maintain versioned backups of security configuration and document the procedure used to restore them.

Wazuh Password Policy and SSO

Single sign-on can significantly simplify password management for enterprise Wazuh deployments.

Instead of maintaining separate credentials for every Wazuh user, an organization can authenticate users through an existing identity provider.

This allows password management and authentication controls to be centralized while Wazuh continues to manage authorization through its own RBAC system.

Local Authentication vs SSO

With local authentication, Wazuh maintains internal users and their credentials.

The basic architecture is:

User
 ↓
Wazuh Dashboard
 ↓
Wazuh authentication infrastructure
 ↓
Local Wazuh/Indexer user
 ↓
Wazuh RBAC

With SSO:

User
 ↓
Wazuh Dashboard
 ↓
Identity Provider
 ↓
Authentication / MFA
 ↓
Wazuh
 ↓
Wazuh RBAC

The second model is usually more attractive for large organizations because authentication policies can be centralized.

When to Use Local Wazuh Accounts

Local accounts remain useful for:

• Small deployments
• Lab environments
• Break-glass administration
• Service accounts
• Recovery scenarios
• Environments without an enterprise identity provider

A local administrator account can provide emergency access if the external identity provider becomes unavailable.

However, break-glass credentials should be tightly controlled and monitored.

Benefits of Centralized Identity Management

Centralized identity management provides a single place to manage:

• Password requirements
• MFA
• Password expiration
• Password history
• Account lockout
• User lifecycle
• Group membership
• Conditional access
• Authentication logs

It also reduces administrative duplication.

Instead of separately disabling an employee in Wazuh, VPN, cloud applications, and other systems, the organization’s identity platform can become the central source of authentication and lifecycle information.

Password Policy Responsibilities When Using SSO

When Wazuh uses an external identity provider, password-policy responsibilities are divided between authentication and authorization.

The identity provider generally handles:

• Password validation
• Password changes
• Password history
• Password expiration
• Account lockout
• MFA
• Authentication risk
• User lifecycle

Wazuh generally handles:

• User authorization
• RBAC
• Role mappings
• Tenant access
• Wazuh-specific permissions

This separation is fundamental.

A Wazuh RBAC role does not replace an identity-provider password policy, and an identity-provider password policy does not determine which Wazuh resources a user can access.

Integrating Wazuh With an Identity Provider

Wazuh supports multiple approaches for integrating external identity systems.

SAML Authentication

Security Assertion Markup Language (SAML) allows Wazuh to participate in an enterprise SSO architecture.

The identity provider authenticates the user and sends an assertion to the service provider.

A typical flow is:

User
 ↓
Wazuh Dashboard
 ↓
Identity Provider
 ↓
SAML authentication
 ↓
SAML assertion
 ↓
Wazuh
 ↓
RBAC authorization

SAML is widely used in enterprise environments where centralized SSO and identity lifecycle management are already established.

Related Guide: How to Configure Wazuh SAML Authentication

OpenID Connect (OIDC)

OpenID Connect provides another SSO option based on OAuth 2.0.

OIDC can be particularly useful when an organization already uses an identity platform that provides OIDC endpoints.

The identity provider handles user authentication, while Wazuh uses the resulting identity information to establish the authenticated user context.

Related Guide: How to Configure Wazuh OIDC

Okta

Organizations using Okta can integrate Wazuh into their existing identity architecture.

This allows administrators to centralize controls such as:

• Password policy
• MFA
• User lifecycle
• Conditional access
• Authentication monitoring

Wazuh can then focus on authorization and security-data access.

Related Guide: How to Integrate Wazuh with Okta

Microsoft Entra ID

Microsoft Entra ID can provide centralized authentication for organizations already using Microsoft identity services.

This can allow Wazuh users to inherit enterprise authentication controls rather than maintaining independent Wazuh passwords.

Related Guide: How to Integrate Wazuh with Azure AD

Google Workspace

Google Workspace can provide centralized identity and authentication for organizations using Google as their identity platform.

Password policies, MFA, account lifecycle, and other authentication controls can remain centralized while Wazuh manages application-specific authorization.

Related Guide: How to Integrate Wazuh with Google Workspace

Keycloak

Keycloak is an open-source identity and access-management platform that can provide centralized authentication for Wazuh.

It can be useful for organizations that want control over their identity infrastructure or need an on-premises identity provider.

Related Guide: How to Integrate Keycloak with Wazuh

Password Policies in SSO Environments

SSO changes where password policies are enforced.

When users authenticate through an external identity provider, Wazuh does not necessarily receive or validate the user’s password itself.

Where Password Requirements Are Enforced

The architecture can be summarized as:

                    ┌──────────────────────┐
                    │  Identity Provider   │
                    │                      │
User ──────────────►│ Password policy      │
                    │ MFA                  │
                    │ Lockout              │
                    │ Password lifecycle   │
                    └──────────┬───────────┘
                               │
                               │ Authentication
                               ▼
                    ┌──────────────────────┐
                    │        Wazuh         │
                    │                      │
                    │ Authentication trust │
                    │ RBAC                 │
                    │ Role mapping         │
                    │ Tenant permissions   │
                    └──────────────────────┘

This means administrators should not duplicate password-policy settings unnecessarily inside Wazuh.

Identity-Provider Password Policies

The identity provider can enforce:

• Minimum password length
• Password complexity
• Password history
• Password expiration
• Compromised-password detection
• Account lockout
• MFA
• Risk-based authentication

The exact capabilities depend on the identity platform.

This is often preferable to maintaining independent password policies across multiple applications.

Wazuh Authorization Versus Authentication

The distinction can be summarized as:

Identity provider:

Is this really the user?

Wazuh:

What is this authenticated user allowed to do?

For example:

Alice authenticates through Okta
              ↓
Okta verifies password + MFA
              ↓
Wazuh receives authenticated identity
              ↓
Wazuh maps Alice to SOC-Analyst role
              ↓
Alice receives analyst permissions

If Alice attempts an administrative action outside her role, Wazuh should deny the operation even though her authentication was successful.

Combining SSO With Wazuh RBAC

SSO and RBAC should be used together.

SSO provides centralized authentication.

Wazuh RBAC provides Wazuh-specific authorization.

For example:

This architecture allows administrators to control membership centrally while keeping Wazuh permissions aligned with SOC responsibilities.

Related Guide: How to Configure Wazuh RBAC

Real-World Wazuh Password Policy Example

Consider an enterprise organization operating a 24/7 Security Operations Center with several hundred employees and a large Wazuh deployment.

The SOC uses Wazuh to monitor servers, workstations, cloud workloads, network devices, and security applications.

Rather than maintaining separate passwords for every Wazuh user, the organization integrates Wazuh with its enterprise identity provider.

The resulting security architecture combines centralized authentication, MFA, Wazuh RBAC, strong credentials, and continuous monitoring.

Enterprise SOC Architecture

The organization’s authentication architecture looks like this:

                    Enterprise Identity Provider
                    ┌──────────────────────────┐
                    │ Password policy          │
                    │ MFA                      │
                    │ Account lifecycle        │
                    │ Lockout                  │
                    │ Password history         │
                    └────────────┬─────────────┘
                                 │
                                 │ SSO
                                 ▼
                       ┌──────────────────┐
                       │ Wazuh Dashboard  │
                       └────────┬─────────┘
                                │
                                ▼
                       ┌──────────────────┐
                       │    Wazuh RBAC    │
                       └────────┬─────────┘
                                │
              ┌─────────────────┼─────────────────┐
              ▼                 ▼                 ▼
          Analysts        Responders         Managers
                                │
                                ▼
                       Wazuh Administrators

The identity provider handles authentication while Wazuh determines what each authenticated user can access.

Create Separate Accounts for Analysts, Incident Responders, Managers, and Administrators

The SOC creates separate identities for each employee.

The corresponding groups are:

SOC-Analysts
SOC-Incident-Responders
SOC-Managers
Wazuh-Administrators

These groups are mapped to Wazuh roles.

SOC analysts receive read-oriented permissions for alerts, events, and dashboards.

Incident responders receive additional permissions required to investigate incidents and perform approved response operations.

SOC managers receive broader access to monitoring, reporting, and operational dashboards.

Wazuh administrators receive permissions required to manage users, roles, security configuration, integrations, and the Wazuh platform.

This structure prevents every SOC employee from receiving administrator privileges.

Apply Stronger Controls to Privileged Accounts

Wazuh administrators are placed into a separate privileged identity group.

The organization requires:

• Strong unique passwords
• MFA
• Privileged authentication
• Individual administrator accounts
• Enhanced authentication monitoring
• Regular access reviews

Administrative access is never provided through a shared admin credential for normal daily operations.

A controlled break-glass account is maintained separately for emergency recovery.

Configure Password Length and Complexity Requirements

The enterprise identity provider enforces the organization’s password requirements.

For example, it might require:

• At least 15 characters
• Screening against known compromised passwords
• MFA for privileged accounts
• Strong password-manager practices

For local Wazuh Indexer accounts that remain necessary, administrators configure the supported Indexer password-validation controls.

The organization avoids assuming that local Indexer settings provide enterprise-wide password expiration, history, and lockout.

Instead, those controls are centralized in the identity provider wherever possible.

Configure Failed-Login Protection

The identity provider monitors failed authentication attempts.

Repeated failures can trigger:

• Rate limiting
• Account lockout
• Additional verification
• MFA challenges
• Security alerts

Wazuh independently monitors authentication-related activity so the SOC can investigate suspicious login patterns.

For example:

10 failed logins
        ↓
Identity provider detects anomaly
        ↓
Account protection triggered
        ↓
Wazuh receives security event
        ↓
SOC investigates

This provides both prevention and detection.

Enforce Password History and Expiration Where Appropriate

The organization does not force every Wazuh user to maintain password policies independently.

Instead, password history and lifecycle requirements are implemented through the enterprise identity provider when required.

This creates a consistent policy across:

• Wazuh
• VPN
• Cloud applications
• Internal applications
• Administrative systems

Local Wazuh accounts are treated separately and are limited to accounts that genuinely require local authentication.

Integrate Wazuh With Enterprise SSO and MFA

The SOC integrates Wazuh with its existing SSO platform.

The authentication flow becomes:

User
 ↓
Wazuh Dashboard
 ↓
Enterprise Identity Provider
 ↓
Username + Password
 ↓
MFA
 ↓
Successful authentication
 ↓
Wazuh
 ↓
Group/role mapping
 ↓
Wazuh RBAC
 ↓
Authorized resources

This eliminates the need for hundreds of independent Wazuh passwords while allowing the organization to enforce centralized authentication controls.

Monitor Authentication Events

The SOC monitors authentication activity for unusual behavior.

Examples include:

• Repeated failed logins
• Login attempts from unusual locations
• Privileged-account authentication
• Disabled-account login attempts
• Unexpected service-account activity
• Authentication failures following password rotation

These events can be correlated with endpoint, network, and identity-provider telemetry.

Related Guide: How to Configure Wazuh Audit Logs

Periodically Audit Users and Access Permissions

The SOC performs quarterly access reviews.

The review identifies:

• Inactive Wazuh users
• Users who changed teams
• Excessive privileges
• Unused service accounts
• Administrator accounts
• External identity-provider group membership
• Tenant access
• API credentials

The organization removes inactive accounts and reduces permissions when users no longer require them.

A typical review process is:

Inventory users
      ↓
Review identity-provider membership
      ↓
Review Wazuh roles
      ↓
Review recent authentication activity
      ↓
Remove inactive accounts
      ↓
Reduce excessive privileges
      ↓
Document changes

This creates a continuous access-control process rather than treating password configuration as a one-time deployment task.

The resulting architecture provides multiple layers of protection:

Strong passwords
       +
MFA
       +
Centralized identity
       +
Wazuh RBAC
       +
Least privilege
       +
Authentication monitoring
       +
Regular access reviews

This layered approach is substantially stronger than relying on password complexity alone and provides a scalable model for enterprise Wazuh deployments.

Monitoring and Auditing Wazuh Authentication

Configuring a strong Wazuh password policy is only the first step.

Organizations should also monitor authentication activity and periodically audit user accounts, roles, and administrative actions.

Authentication monitoring helps identify credential attacks, compromised accounts, misconfigured applications, and unauthorized administrative activity.

Monitor Failed Authentication Attempts

Repeated failed authentication attempts can indicate password guessing, brute-force attacks, credential stuffing, or a legitimate user experiencing a configuration problem.

Monitor authentication events across the components involved in the Wazuh authentication flow, including the Wazuh Dashboard, Wazuh Indexer, Wazuh API, and external identity provider.

Useful indicators include:

• Multiple failed logins from the same source
• Failed logins against multiple accounts
• Repeated failures against privileged accounts
• Authentication attempts against disabled accounts
• Authentication failures immediately followed by a successful login
• Authentication attempts from unusual locations

You can investigate Wazuh-related authentication activity in the relevant logs:

sudo journalctl -u wazuh-dashboard
sudo journalctl -u wazuh-indexer
sudo journalctl -u wazuh-manager

For installations using an external identity provider, also review the identity provider’s authentication logs.

Identify Repeated Account Lockouts

Account lockouts can be an important security signal.

A single lockout may simply indicate that a user forgot a password. Repeated lockouts, however, could indicate:

• Password-spraying activity
• Credential stuffing
• A compromised account
• A stale service-account password
• A broken automation process
• An incorrectly configured application

Track lockouts by:

• Username
• Source IP
• Timestamp
• Authentication method
• Application
• Identity provider

A pattern such as multiple users becoming locked from the same source IP should receive particular attention.

Audit Password and Account-Management Activity

Administrative changes to users and credentials should be auditable.

Track events involving:

• User creation
• User deletion
• Password changes
• Password resets
• Account enablement
• Account disablement
• Role changes
• Role mappings
• Authentication-provider changes
• Security configuration changes

This creates an audit trail that can help answer questions such as:

Who changed this account?

When was the password reset?

Who granted this user administrative access?

When was this role mapping modified?

Wazuh audit logging can be used to monitor security-relevant activity within the environment.

Monitor Administrator Authentication

Privileged authentication deserves additional monitoring.

Create visibility into:

• Administrator logins
• Failed administrator logins
• Administrative API authentication
• New administrator accounts
• Changes to administrator roles
• Authentication from unusual sources
• Authentication outside normal operating hours

For example, an administrator account that normally authenticates from a corporate network but suddenly authenticates from an unfamiliar external address should trigger investigation.

Administrator accounts should also have individual identities rather than shared credentials.

Integrate Wazuh Authentication Events With Security Monitoring

Authentication events become more valuable when correlated with other security telemetry.

For example:

Failed authentication
        ↓
Successful authentication
        ↓
New privileged session
        ↓
Administrative configuration change
        ↓
Suspicious endpoint activity

A sequence like this can provide significantly more context than an individual failed-login event.

Wazuh can correlate authentication-related telemetry with endpoint, network, cloud, and application events.

Organizations can also forward security events to their broader SIEM or SOAR infrastructure when appropriate.

Create Alerts for Suspicious Authentication Activity

Create detection rules and alerts for patterns that warrant investigation.

Examples include:

• Excessive failed logins
• Repeated account lockouts
• Privileged-account authentication failures
• Authentication from unexpected locations
• Authentication involving disabled accounts
• New administrative users
• Unexpected role changes
• Authentication followed by suspicious administrative activity

Avoid creating alerts for every individual failed password attempt.

A better approach is to establish thresholds and correlate related events to reduce noise.

Related Guides:

• How to Create Custom Detection Rules in Wazuh (With Examples)
•  How to Reduce False Positives in Wazuh

Frequently Asked Questions

Question: What Is a Wazuh Password Policy?

A Wazuh password policy is a set of controls governing how passwords and authentication credentials are managed for users accessing Wazuh components.

Depending on the authentication architecture, these controls can include:

• Minimum password length
• Password complexity
• Password validation
• Password history
• Password expiration
• Failed-login protection
• Account lockout
• Password-reset procedures

An important distinction is that these controls are not necessarily implemented by one Wazuh configuration file.

Local Wazuh Indexer users, Wazuh API users, and externally authenticated SSO users can be governed by different authentication mechanisms.

Question: Where Is the Wazuh Password Policy Configured?

There is not necessarily one universal Wazuh password-policy configuration.

For local Wazuh Indexer users, password validation is associated with the OpenSearch Security plugin used by the Wazuh Indexer.

Security configuration is commonly located under:

/etc/wazuh-indexer/opensearch-security/

For Wazuh API users, credentials are managed through Wazuh’s API user-management mechanisms.

For SSO deployments, password requirements are generally configured in the external identity provider.

Therefore, first determine which authentication backend your Wazuh deployment uses before changing password settings.

Related Guide: How to Configure Wazuh SSO

Question: Does Wazuh Support Password Complexity Requirements?

Yes, supported Wazuh Indexer/OpenSearch Security configurations can provide password validation for local users.

Depending on the installed version, supported controls can include minimum password length and password-validation rules.

The exact available parameters depend on the Wazuh and OpenSearch Security versions installed.

Do not assume that a password-policy setting documented for a newer OpenSearch release is supported by every Wazuh version.

Question: How Do I Change the Minimum Wazuh Password Length?

For local Wazuh Indexer users, the minimum password length can be configured through the supported OpenSearch Security password-validation settings.

For example, a supported configuration may contain:

plugins.security.restapi.password_min_length: 12

The exact parameter and configuration process should be verified against your Wazuh version before applying the change.

After making the change, apply the security configuration and test it with a dedicated account.

Question: Can I Configure Wazuh Password Expiration?

This depends on the authentication backend.

If users authenticate through an external identity provider such as Okta, Microsoft Entra ID, Google Workspace, LDAP, or another enterprise identity system, password expiration can generally be managed by that provider.

For local Wazuh Indexer users, do not assume that a traditional enterprise password-expiration policy is available simply because password validation is supported.

If password expiration is a business requirement, an external identity provider can provide a more comprehensive password lifecycle-management solution.

Question: Does Wazuh Support Password History?

Password-history enforcement depends on the authentication backend and the specific version and security configuration being used.

For enterprise SSO deployments, password history is normally handled by the identity provider.

This is one reason centralized identity management can be preferable to maintaining independent local passwords across applications.

Question: Can I Lock a Wazuh Account After Failed Login Attempts?

Account lockout depends on the authentication system handling the user’s credentials.

If the identity provider supports account lockout, configure the policy there.

For local Wazuh authentication, verify the capabilities of the Wazuh Indexer/OpenSearch Security version being used rather than assuming that all enterprise password-policy features are available.

For production environments, failed-login protection should be tested with a dedicated account.

Question: How Do I Reset a Wazuh User Password?

The procedure depends on which type of Wazuh user you are resetting.

Wazuh provides password-management tooling for Wazuh API and Wazuh Indexer users.

For example, Wazuh documents the wazuh-passwords-tool.sh utility for password-management operations.

If the user is authenticated through SAML, OIDC, Okta, Microsoft Entra ID, Google Workspace, or another external identity provider, reset the password through that identity system instead.

Question: How Do I Unlock a Wazuh User Account?

First determine where the account is authenticated.

For an externally authenticated user, unlock the account through the identity provider or directory service.

For a local Wazuh Indexer user, use the appropriate Wazuh/OpenSearch Security user-management procedure for your installed version.

Do not manually modify security indexes or internal configuration files unless the documented procedure specifically requires it.

After unlocking the account, verify that the user can authenticate and that the expected Wazuh roles are still assigned.

Question: Does Wazuh Support MFA?

Wazuh can participate in an MFA-protected authentication architecture through supported external identity providers.

For example, an organization can authenticate Wazuh users through an identity provider that requires:

Username
   +
Password
   +
MFA

The identity provider handles authentication and MFA while Wazuh handles application-specific authorization.

This is generally preferable for enterprise deployments because MFA can be centrally enforced across multiple applications.

Question: Can Wazuh Password Policies Be Used With SSO?

Yes, but password-policy responsibilities change when SSO is introduced.

With local authentication, password controls may be handled by Wazuh’s authentication components.

With SSO, the identity provider generally handles:

• Password requirements
• Password changes
• Password history
• Password expiration
• Account lockout
• MFA

Wazuh then uses the authenticated identity to apply RBAC and resource permissions.

The two systems therefore complement rather than replace each other.

Question: Does Wazuh Support SAML and OIDC Authentication?

Yes. Wazuh supports SSO architectures using SAML and OpenID Connect, subject to the capabilities and configuration of the Wazuh version being deployed.

SAML and OIDC allow Wazuh to integrate with enterprise identity providers and centralize authentication.

Related Guides:

• How to Configure Wazuh SAML Authentication
• How to Configure Wazuh OIDC

Question: How Do I Troubleshoot Wazuh Password Policy Problems?

Start by identifying the authentication backend.

Then check:

1. The Wazuh version.
2. The Wazuh Indexer/OpenSearch Security version.
3. The active authentication configuration.
4. The relevant password-policy settings.
5. Whether the configuration was actually applied.
6. Wazuh Indexer logs.
7. Wazuh Dashboard logs.
8. Wazuh API logs.
9. External identity-provider logs, if applicable.
10. User roles and role mappings.

Also distinguish authentication errors from authorization errors.

A 401 Unauthorized response generally indicates an authentication problem, while a 403 Forbidden response generally indicates that authentication succeeded but the user lacks the required permissions.

Conclusion

A properly designed Wazuh password policy provides an important layer of protection for Wazuh users, administrators, APIs, and security infrastructure.

However, password complexity alone is not enough.

A secure Wazuh deployment should combine strong authentication with authorization controls and continuous monitoring.

At a minimum, organizations should:

• Use long, unique passwords.
• Protect privileged accounts with stronger controls.
• Avoid shared administrator credentials.
• Use dedicated service accounts.
• Apply least-privilege RBAC.
• Monitor failed authentication attempts.
• Review users and permissions regularly.
• Remove inactive accounts.
• Back up security configuration before making changes.

For enterprise deployments, integrating Wazuh with an identity provider can provide an even stronger authentication architecture.

SSO centralizes password management, while MFA adds an additional authentication factor. Wazuh RBAC then controls what authenticated users can access.

The resulting model is:

Strong authentication
        +
SSO
        +
MFA
        +
Wazuh RBAC
        +
Least privilege
        +
Authentication monitoring
        +
Regular access reviews

This layered approach reduces the risk associated with stolen credentials while making user lifecycle management more consistent across the organization.

Finally, treat password-policy configuration as an ongoing security process rather than a one-time configuration task.

Periodically review authentication events, privileged accounts, service accounts, roles, and identity-provider group memberships to ensure that Wazuh access continues to match the organization’s security requirements.

Related Guides:

•  The Complete Wazuh Cluster Architecture Guide
• The Ultimate Wazuh Indexer Guide