Mastering Wazuh Security: The Complete Access Control Guide

Modern security operations centers rarely have a single administrator responsible for every Wazuh function. A typical enterprise deployment may include Wazuh administrators who manage infrastructure, security analysts who investigate alerts, incident responders who need additional operational capabilities, auditors who require read-only visibility, and business or compliance teams that should only see specific security data. This is where Wazuh access control becomes an essential part of a secure deployment.

Giving every user the same level of access creates unnecessary risk.

A compromised analyst account with administrator privileges, for example, could potentially be used to modify detection rules, manage agents, change security settings, or access information outside the analyst’s responsibilities.

Wazuh access control determines who can authenticate to the platform, what resources they can access, what actions they can perform, and which security data they are permitted to see.

It combines authentication mechanisms, role-based authorization, permissions, role mappings, tenants, data restrictions, API controls, and network-level protections to establish security boundaries around the Wazuh environment.

Wazuh’s own documentation describes RBAC as a mechanism for controlling access to Wazuh server API endpoints and resources according to user privileges, explicitly aligning the model with the principle of least privilege.

What Is Wazuh Access Control?

Wazuh access control is the collection of mechanisms used to authenticate users and authorize their access to Wazuh resources and functionality.

In practical terms, access control answers questions such as:

• Who is allowed to log in to the Wazuh Dashboard?
• How is a user’s identity verified?
• Which users can view security alerts?
• Which analysts can access particular tenants?
• Who can manage Wazuh agents?
• Who can modify detection rules?
• Who can administer users and roles?
• Which API endpoints can a user access?
• Which indexed security documents or fields can a user see?
• Which networks are allowed to reach Wazuh services?
• Which administrative actions should be recorded for auditing?

Wazuh provides several layers through which these decisions can be enforced.

Internal users and roles can be managed within Wazuh, while enterprise environments can also integrate external identity systems such as LDAP, Active Directory, SAML, and other supported identity providers.

Wazuh’s user-administration documentation specifically separates user authentication, role management, RBAC, SSO, and LDAP integration into distinct administrative capabilities.

Access control therefore should not be thought of as a single setting.

It is better understood as a security architecture spanning identity, authorization, data access, APIs, and network boundaries.

Authentication vs. Authorization in Wazuh

First, authentication and authorization are closely related, but they solve different security problems.

Authentication answers:

“Who are you?”

Authorization answers:

“What are you allowed to do?”

For example, suppose an analyst logs in to the Wazuh Dashboard with a valid corporate identity.

Authentication establishes that the person is associated with that identity.

Authorization then determines whether that user can view alerts, access a particular tenant, manage agents, modify rules, administer users, or perform other privileged operations.

A successful login does not automatically mean that the user should have unrestricted access to the Wazuh platform.

This distinction is especially important in enterprise environments.

A security analyst may be successfully authenticated but still be denied access to administrative functions.

Likewise, an auditor may be authenticated successfully while receiving only read-only access to selected security information.

Wazuh supports both native user management and integration with external identity systems.

In LDAP environments, for example, Wazuh distinguishes authentication from authorization: LDAP can authenticate the user while directory attributes and backend roles contribute to determining what that user is allowed to access.

Why Access Control Matters in a Wazuh Deployment

A Wazuh installation can contain highly sensitive information, including endpoint telemetry, authentication events, vulnerability information, malware detections, network activity, compliance data, file-integrity events, and incident-response information.

Poor access control can therefore create several security problems.

An overly privileged account could potentially:

• Modify detection and response configurations
• Create or remove users
• Change role assignments
• Access sensitive security data
• Modify agent configurations
• Interact with Wazuh APIs
• Access administrative interfaces
• Alter index or data-management settings
• Circumvent intended organizational boundaries

The risk becomes greater as a Wazuh deployment grows.

A small laboratory installation may have only one administrator.

An enterprise SOC can have dozens or hundreds of users with significantly different responsibilities.

Access control allows the organization to establish those boundaries explicitly.

For example, an organization might implement the following model:

The exact permissions should be determined by the organization’s operational requirements rather than by job title alone.

The Principle of Least Privilege

The foundation of effective Wazuh access control is least privilege.

Least privilege means that users, applications, and processes should receive only the permissions necessary to perform their assigned responsibilities.

NIST defines least privilege as restricting access privileges to the minimum necessary to accomplish assigned tasks.

NIST SP 800-53 also identifies least privilege as control AC-6 and connects it with access enforcement and separation of duties.

For Wazuh, this means avoiding the common mistake of assigning administrative privileges simply because they are convenient.

Instead of giving every SOC employee an administrator role, an organization can create specialized permissions:

• Analysts receive permissions required for investigation.
• Responders receive additional permissions required for approved response activities.
• Auditors receive read-only access.
• Administrators receive infrastructure and security-management privileges.
• External users receive access only to the tenants and data they require.

This approach reduces the potential impact of credential compromise and limits accidental changes made by legitimate users.

It also supports separation of duties.

For example, an organization may decide that the person responsible for administering Wazuh access controls should not automatically have unrestricted authority over audit processes.

Wazuh Access Control in an Enterprise SOC

In an enterprise SOC, Wazuh access control should be designed around responsibilities, trust boundaries, and data sensitivity.

Consider a SOC with four primary groups:

1. Wazuh administrators manage the platform.
2. Security analysts investigate alerts and events.
3. Incident responders perform approved response activities.
4. Auditors review security and compliance information.

Each group can receive a different access profile.

RBAC provides the primary mechanism for expressing these differences.

Multi-tenancy can then separate security data between teams or environments, while field-level and document-level restrictions can provide more granular control over the information exposed to users.

Our dedicated RBAC configuration guide covers the implementation details: How to Configure Wazuh RBAC

For organizations using multiple tenants, the access-control model can be extended so that users receive both appropriate permissions and access to the appropriate security-data boundaries.

Related Guide: How to Set Up Wazuh Multi-Tenancy

The result is a layered access-control model rather than a simple username-and-password system.

How Wazuh Access Control Works

Wazuh access control operates across several interconnected components.

The Wazuh Dashboard provides the primary user interface, the Wazuh server exposes management capabilities through its API, and the Wazuh indexer stores and serves security data.

The Wazuh architecture consists of the Wazuh agent and three central components: the Wazuh server, Wazuh indexer, and Wazuh Dashboard.

Agents send events to the server for analysis, the server forwards analyzed data to the indexer, and the Dashboard provides visualization and management capabilities.

Access control is applied at different points within this architecture.

Wazuh Dashboard Authentication

The Wazuh Dashboard is normally the primary entry point for human users.

A user authenticates to the Dashboard using an internal Wazuh identity or an integrated external identity provider, depending on the deployment.

Enterprise environments can integrate Wazuh with identity-management technologies such as:

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

After authentication, the user’s identity and associated roles determine what the user can access.

The Dashboard itself is therefore not simply a visualization layer.

It is also an important enforcement point for user access, role assignments, tenant access, and administrative capabilities.

Wazuh’s documentation notes that the Dashboard supports user management, roles, role mappings, RBAC, and SSO policies.

Wazuh API Access Control

The Wazuh server API provides programmatic access to Wazuh management functionality.

The API can be used for operations such as managing agents, controlling managers, retrieving FIM information, accessing ruleset information, testing rules and decoders, and administering RBAC.

Because an API can perform privileged operations without the Dashboard’s visual interface, API access control is particularly important.

Wazuh API endpoints require authentication, and the API uses JWT-based authentication for authenticated requests.

Wazuh also provides RBAC mechanisms for controlling access to API resources and endpoints.

This means an authenticated API user still needs the appropriate authorization before performing a privileged operation.

For example, successfully obtaining an API token should not be interpreted as permission to:

• Add or remove agents
• Modify configuration
• Manage users
• Change roles
• Restart services
• Alter security settings

The user’s assigned permissions determine which operations are actually authorized.

Wazuh Indexer Security

The Wazuh indexer represents another major access-control boundary.

It stores Wazuh security information as indexed JSON documents and provides the search and analytics layer used by the Dashboard.

The indexer has its own security model, including users, roles, role mappings, permissions, and controls over access to indexed data.

This distinction matters because Wazuh access control is not limited to deciding whether someone can log in to the Dashboard.

A user might be authenticated successfully but still need authorization to access particular indexes, documents, or fields.

The Wazuh indexer API itself requires authentication and supports authorization responses such as HTTP 401 for unauthorized requests and HTTP 403 for permission-denied requests.

Security Roles and Permissions

Roles are the mechanism used to group permissions into reusable authorization profiles.

Instead of manually assigning individual permissions to every user, administrators can create roles representing specific responsibilities.

For example:

• wazuh_analyst
• wazuh_responder
• wazuh_auditor
• wazuh_admin

The permissions assigned to those roles determine what members of each group can do.

Wazuh’s server-side RBAC model uses users, roles, rules, and policies.

Users are assigned roles, while roles group the rules and policies that determine permitted actions on resources.

This structure makes access control easier to manage at scale.

If an organization decides that all analysts should receive access to an additional resource, administrators can modify the analyst role rather than individually changing dozens of accounts.

For detailed implementation instructions: How to Configure Wazuh RBAC

Role Mappings

A role defines permissions, but a role mapping connects those permissions to users or groups.

This becomes particularly important when Wazuh is integrated with an enterprise identity provider.

For example, an organization could map an identity-provider group such as:

SOC-Analysts

to a Wazuh analyst role.

Likewise:

SOC-Admins

could map to an administrative role, while:

SOC-Auditors

could map to a read-only auditing role.

Wazuh’s RBAC documentation describes role mappings as the mechanism used to associate internal users with Wazuh roles.

Role mappings are therefore an important bridge between identity management and authorization management.

Users and Backend Roles

A Wazuh user represents the authenticated identity, while backend roles and mapped roles can be used to determine what that identity is permitted to access.

In an enterprise deployment, this allows the authorization model to follow organizational structures rather than requiring every permission to be managed manually.

For example:

Identity Provider
       |
       v
   User / Group
       |
       v
   Role Mapping
       |
       v
   Wazuh Role
       |
       v
Permissions / Policies
       |
       v
Wazuh Resources

This model is especially useful when employee responsibilities change.

Moving a user from one security group to another can change their effective Wazuh permissions without manually rebuilding their entire account.

Tenants and Data Isolation

Permissions determine what users can do, while tenants can help determine which security data they can access.

Multi-tenancy is particularly useful for organizations that operate multiple SOC teams, business units, customers, environments, or security domains within the same Wazuh deployment.

For example:

• The Windows SOC team could receive one tenant.
• The Linux infrastructure team could receive another.
• A compliance team could receive a restricted tenant.
• A managed security provider could isolate customers by tenant.

This creates a separation between platform permissions and data visibility.

For a complete implementation guide: How to Set Up Wazuh Multi-Tenancy

Field-Level and Document-Level Restrictions

Access control can become even more granular when organizations need to restrict specific security information rather than entire datasets.

Document-level restrictions control which documents a user can access.

Field-level restrictions control which fields within accessible documents are exposed.

This is useful when users need access to security events but should not necessarily see every piece of information contained within those events.

For example, an analyst might need access to endpoint security alerts but not certain sensitive fields associated with another business unit.

Related Guide: How to Configure Wazuh Field Level Security

Field-level and document-level restrictions should be designed carefully because overly restrictive policies can interfere with investigations, dashboards, searches, or operational workflows.

Audit Logging

A mature access-control strategy must also answer another question:

“Who changed the access-control configuration?”

Audit logging provides visibility into authentication events, administrative changes, role modifications, and other security-relevant activity.

This becomes particularly important for privileged accounts.

Organizations should monitor events such as:

• User creation
• User deletion
• Role creation
• Role modification
• Role mapping changes
• Permission changes
• Authentication failures
• Administrative logins
• Privileged API activity
• Configuration changes

Wazuh can be configured to support auditing of security-relevant activity, allowing organizations to investigate suspicious administrative behavior and demonstrate accountability.

Related Guide: How to Configure Wazuh Audit Logs

Network-Level Access Restrictions

Identity-based authorization should not be the only security boundary.

Network controls can provide an additional layer of defense by restricting which systems are permitted to reach Wazuh services in the first place.

For example, an organization might allow:

• Dashboard access only from the SOC network
• API access only from administrator workstations
• Indexer access only from Wazuh components
• Agent communication only from trusted endpoint networks
• Administrative access only through a VPN or controlled reverse proxy

Wazuh recommends restricting network access to the indexer using controls such as security groups and firewalls to limit exposure to trusted networks.

This creates a defense-in-depth model:

Network Boundary
       |
       v
Authentication
       |
       v
Role Mapping
       |
       v
Authorization
       |
       v
Tenant / Data Restrictions
       |
       v
Field / Document Restrictions
       |
       v
Audit Logging

For implementation guidance on IP-based restrictions: How to Configure a Wazuh IP Whitelist

Wazuh Access Control Architecture

Understanding the individual access-control mechanisms is useful, but enterprise deployments become much easier to secure when the complete Wazuh architecture is viewed as a set of trust boundaries.

A simplified access-control architecture looks like this:

                     ┌─────────────────────┐
                     │   Identity Provider │
                     │ LDAP / SAML / OIDC  │
                     └──────────┬──────────┘
                                │
                         Authentication
                                │
                                v
                     ┌─────────────────────┐
                     │  Wazuh Dashboard    │
                     │ Authentication      │
                     │ Role Mapping        │
                     │ Tenant Access       │
                     └───────┬─────┬───────┘
                             │     │
                   API calls │     │ Data queries
                             │     │
                             v     v
                   ┌──────────┐  ┌──────────────┐
                   │ Wazuh    │  │ Wazuh        │
                   │ Server   │  │ Indexer      │
                   │ API/RBAC │  │ Security     │
                   └────┬─────┘  │ Roles        │
                        │        │ Permissions  │
                        │        └──────┬───────┘
                        │               │
                        v               v
                   Wazuh Manager     Security Data
                   & Analysis        & Indexes

Each component has a distinct responsibility, and access decisions can be enforced at multiple points.

Wazuh Manager

The Wazuh manager is responsible for analyzing security events, applying rules and decoders, managing agents, and generating alerts.

In current Wazuh architecture documentation, the Wazuh server comprises the Wazuh manager and Filebeat, with the manager handling analysis and alerting while Filebeat forwards data to the indexer.

From an access-control perspective, the manager is important because it exposes management functionality through the Wazuh server API.

An administrator may use the API to:

• Manage agents
• Retrieve agent information
• Control manager functionality
• Access FIM information
• Manage security configurations
• Manage users and roles
• Perform other administrative operations

Consequently, protecting the Wazuh API is an essential part of protecting the manager itself.

Wazuh Indexer

The Wazuh indexer stores and serves the security data generated by the Wazuh environment.

It is therefore one of the most important data-protection boundaries in the platform.

Indexer security controls determine which authenticated identities can perform operations against indexed data.

The indexer also exposes its own API, which supports authentication and authorization.

Wazuh recommends using HTTPS, changing default administrative credentials, and restricting network access to the indexer API.

The indexer’s security layer is particularly important in multi-user environments because compromising data access can be just as damaging as gaining administrative control.

Wazuh Dashboard

The Wazuh Dashboard provides the primary user-facing interface.

It allows users to:

• Investigate alerts
• Search security events
• Monitor agents
• Review vulnerabilities
• Analyze compliance information
• Manage Wazuh configuration
• Access API consoles
• Configure security roles and users

Because the Dashboard brings together so many functions, it becomes a central point for authentication and authorization.

A properly configured Dashboard should ensure that users receive only the menus, data, and operational capabilities appropriate to their assigned roles.

Wazuh API

The Wazuh API provides programmatic access to the Wazuh server.

It is used heavily by the Dashboard but can also be accessed through command-line tools, scripts, automation platforms, and other applications.

Wazuh documents the API as a RESTful interface that enables remote management of the Wazuh infrastructure, including agent management, manager operations, FIM information, ruleset information, and RBAC functionality.

Because APIs can expose powerful administrative operations, they should be treated as privileged interfaces.

Authentication establishes the identity making the request, while RBAC determines whether that identity is authorized to perform the requested operation.

Security Plugin and Access-Control Components

The Wazuh indexer uses its security functionality to manage users, roles, role mappings, and permissions for indexed data.

At the Wazuh server API layer, RBAC uses:

• Users
• Roles
• Rules
• Policies
• Resources
• Actions

Wazuh’s RBAC architecture explicitly separates these concepts so that roles can group the rules and policies necessary for specific operational responsibilities.

This separation is important because it allows an organization to build reusable authorization models instead of assigning permissions independently to every account.

Authentication and Authorization Flow

A typical user access flow can be represented as follows:

1. User initiates a connection

The user opens the Wazuh Dashboard or accesses an authorized API.

2. Authentication occurs

The user authenticates using an internal Wazuh account or an integrated identity provider.

3. Identity attributes are evaluated

The system determines the user’s identity and associated roles or backend roles.

4. Role mappings are applied

The user’s identity is mapped to the appropriate Wazuh roles.

5. Permissions are evaluated

The requested operation is checked against the permissions associated with those roles.

6. Data restrictions are evaluated

Tenant, index, document-level, or field-level restrictions may further constrain what information the user can access.

7. Network controls are enforced

Firewalls, reverse proxies, security groups, and other network controls determine whether the source is permitted to reach the service.

8. The request is allowed or denied

The final decision determines whether the requested resource or operation is accessible.

9. Security activity is audited

Relevant authentication, authorization, and administrative activity can be recorded for monitoring and investigation.

This layered model prevents authentication from becoming the sole security boundary.

How Wazuh Components Communicate Securely

Wazuh’s components communicate over defined network services and use encryption for important communication paths.

For example, Wazuh documents that:

• Agent-to-server communication uses encrypted Wazuh messaging.
• Wazuh server-to-indexer communication uses TLS through Filebeat.
• Dashboard-to-server API communication uses HTTPS/TLS.
• Dashboard-to-indexer communication uses secured communication mechanisms.
• The Wazuh indexer API can be protected using HTTPS.

The official architecture documentation identifies common service ports including TCP 1514 for agent communication, TCP 1515 for enrollment, TCP 1516 for cluster communication, TCP 55000 for the Wazuh server API, TCP 9200 for the indexer API, and TCP 443 for the Dashboard.

Security teams should avoid exposing these services unnecessarily.

Encryption protects communications in transit, while authentication and authorization determine whether a party is permitted to use the service.

These are complementary controls rather than substitutes for one another.

Where Access Policies Are Enforced

One of the most important concepts in Wazuh access control is that there is no single enforcement point.

Different controls operate at different layers:

This layered approach is what makes enterprise-grade Wazuh access control possible.

A network firewall can prevent an unauthorized host from reaching the Dashboard, but it cannot determine whether an authenticated analyst should be allowed to delete an agent.

Similarly, an RBAC role can restrict administrative actions, but it cannot replace network segmentation.

Effective Control

Effective access control therefore combines network security, authentication, authorization, data isolation, least privilege, and auditing.

For organizations implementing Wazuh RBAC, the access-control architecture should be documented as a complete system rather than as a collection of unrelated settings.

Related Guide: Troubleshooting Wazuh RBAC

Organizations should also maintain recoverable copies of their access-control configuration so that role mappings and permissions can be restored following an infrastructure failure or configuration mistake.

Related Guide: How to Backup Wazuh RBAC Configurations

Finally, access control should be treated as an ongoing security process.

Users change roles, employees leave organizations, new SOC teams are created, data boundaries evolve, and new integrations introduce additional authentication paths.

Regular reviews are therefore necessary to ensure that permissions continue to match actual job responsibilities.

A strong Wazuh access-control architecture ultimately follows the same principle emphasized by NIST: give each identity only the access required to perform its authorized responsibilities, and enforce those boundaries consistently across the system.

Wazuh Authentication vs Authorization

Authentication and authorization are two separate but interconnected components of Wazuh access control.

Authentication establishes the identity of the person, service, or application attempting to access Wazuh, while authorization determines what that authenticated identity is permitted to access or modify.

Understanding this distinction is critical when designing a secure Wazuh deployment.

A user can successfully authenticate and still receive a 403 Forbidden response, be unable to access a particular tenant, or be denied access to an administrative operation because the identity does not have the required permissions.

What Authentication Means in Wazuh

Authentication is the process of verifying an identity.

When a user attempts to access the Wazuh Dashboard, the system must first determine whether the supplied credentials or external identity are valid.

Depending on the deployment, Wazuh can authenticate users through mechanisms such as:

• Local Wazuh users
• LDAP
• Active Directory
• SAML
• OpenID Connect
• Other supported SSO configurations

The authentication mechanism answers:

“Is this really the user or identity they claim to be?”

Once authentication succeeds, the resulting identity can be passed into the authorization process.

Authentication should therefore be considered the first security gate, not the complete access-control system.

What Authorization Means in Wazuh

Authorization determines what an authenticated identity is allowed to do.

For example, imagine that two users successfully authenticate to the same Wazuh Dashboard.

An administrator might be allowed to:

• Create users
• Modify roles
• Manage agents
• Change security configuration
• Access administrative APIs

A security analyst might only be allowed to:

• View alerts
• Search security events
• Investigate endpoint activity
• Access assigned tenants

Both users are authenticated, but their authorization levels are different.

Wazuh uses RBAC and other access-control mechanisms to enforce these differences.

The authorization decision can depend on factors such as:

• Assigned roles
• Permissions
• Backend roles
• Role mappings
• Tenants
• Index permissions
• Document-level restrictions
• Field-level restrictions
• API privileges

This is why simply protecting the Wazuh Dashboard with a strong password does not constitute a complete access-control strategy.

Local Wazuh Users

Local users are identities managed directly within the Wazuh security configuration rather than being authenticated through an external enterprise identity provider.

This approach can be useful for:

• Small Wazuh deployments
• Laboratory environments
• Emergency administrative accounts
• Break-glass access
• Environments without centralized identity management

A local administrative account can also provide a recovery path if an external identity provider becomes unavailable.

However, organizations should avoid creating large numbers of independent local accounts when centralized identity management is available.

Local accounts introduce additional administrative overhead because security teams must manage:

• Passwords
• Account lifecycle
• Password changes
• Account disabling
• Role assignments
• Access reviews

A recommended enterprise pattern is to maintain a tightly controlled local administrative or break-glass account while using centralized identity management for normal user access.

For the underlying Wazuh user-administration model, see the official Wazuh documentation.

SSO Authentication

Single sign-on (SSO) allows users to authenticate through an existing enterprise identity system rather than maintaining separate Wazuh credentials for every employee.

This can centralize:

• User lifecycle management
• Authentication policies
• MFA
• Password policies
• Account disabling
• Group membership
• Identity auditing

For example, an organization might maintain groups such as:

Wazuh-Administrators
Wazuh-Analysts
Wazuh-Responders
Wazuh-Auditors

Membership in these groups can then be mapped to appropriate Wazuh roles.

This produces a cleaner separation between identity management and security authorization.

Our

dedicated SSO article can cover the implementation details: How to Configure Wazuh SSO

SAML Authentication

Security Assertion Markup Language (SAML) is commonly used for enterprise web-based SSO.

With SAML, an identity provider authenticates the user and sends an assertion containing identity information to the service provider.

A simplified flow looks like this:

User
  |
  v
Wazuh Dashboard
  |
  v
Identity Provider
  |
  | Authentication
  v
SAML Assertion
  |
  v
Wazuh
  |
  v
Role Mapping
  |
  v
Authorized Resources

The important point is that SAML authentication does not automatically determine every Wazuh permission.

The authenticated identity still needs to be mapped to appropriate roles and access policies.

For example, a SAML group representing SOC analysts could be mapped to an analyst role, while a security-administrator group receives administrative privileges.

Related Guide: How to Configure Wazuh SAML Authentication

OpenID Connect (OIDC)

OpenID Connect is another identity protocol that can be used for SSO.

OIDC builds on OAuth 2.0 and uses identity tokens to communicate authenticated user information between the identity provider and relying application.

An enterprise Wazuh deployment could use an OIDC provider to authenticate users and then use identity claims or group information to determine their Wazuh roles.

A simplified flow is:

User
  |
  v
Wazuh Dashboard
  |
  v
OIDC Identity Provider
  |
  | ID Token / Claims
  v
Wazuh
  |
  v
Role Mapping
  |
  v
Permissions

OIDC is particularly useful when the organization already has an identity platform that supports modern OAuth 2.0 and OpenID Connect workflows.

Related Guide: How to Configure Wazuh OIDC

LDAP Authentication

LDAP provides another method for integrating Wazuh authentication with centralized directory services.

Organizations using LDAP or Active Directory can authenticate users against an existing directory rather than maintaining separate Wazuh credentials.

LDAP integration can also allow directory groups to participate in authorization decisions.

For example:

Active Directory
       |
       v
SOC-Analysts
       |
       v
LDAP Authentication
       |
       v
Wazuh Role Mapping
       |
       v
Analyst Permissions

This approach is particularly valuable for large organizations because access can be tied to existing organizational groups.

When an employee leaves the organization and their directory account is disabled, access to Wazuh can be revoked through the centralized identity system.

Related Guide: How to Configure Wazuh LDAP Authentication

How Authenticated Identities Are Mapped to Permissions

Authentication and authorization become connected through role mapping.

The general process is:

1. The user authenticates.
2. Wazuh receives the authenticated identity.
3. Identity attributes or backend roles are evaluated.
4. Role mappings associate the identity with Wazuh roles.
5. The assigned roles provide permissions.
6. Tenant and data restrictions are applied where configured.
7. The requested operation is allowed or denied.

For example:

Employee
   |
   v
Azure AD / LDAP / SAML / OIDC
   |
   v
SOC-Analysts Group
   |
   v
Wazuh Role Mapping
   |
   v
wazuh_analyst
   |
   +--> Alert Read
   +--> Event Search
   +--> Dashboard Access
   |
   X--> User Administration
   X--> Role Administration
   X--> Security Configuration

This model is preferable to assigning permissions individually whenever possible.

It allows administrators to manage access based on organizational responsibilities while keeping authorization policies centralized.

Common Authentication and Authorization Mistakes

Several configuration mistakes repeatedly cause access-control problems in Wazuh.

Confusing authentication with authorization

A successful login only proves that the identity was authenticated. It does not mean the user has permission to perform every operation.

Giving everyone administrator privileges

This defeats least privilege and increases the impact of a compromised account.

Incorrect role mappings

A user may authenticate successfully but receive unexpected permissions because the identity-provider group or backend role is mapped incorrectly.

Using overlapping roles without understanding effective permissions

Multiple roles can produce a broader effective permission set than administrators expect.

Failing to review external identity groups

An employee can retain Wazuh access if their identity-provider membership is not properly removed.

Using local accounts for every user

This creates unnecessary account-management overhead and makes centralized lifecycle management more difficult.

Ignoring API authorization

A user who cannot perform an operation through the Dashboard should not automatically be assumed to be unable to perform it through the API.

Forgetting tenant restrictions

A user can have an appropriate role but still require tenant-level restrictions to prevent access to another team’s data.

Making security changes without testing

Access-control changes can unintentionally lock out administrators or expose data to users who should not have access.

A controlled test account for each major role is therefore extremely useful.

Configure Wazuh Role-Based Access Control (RBAC)

Wazuh Role-Based Access Control (RBAC) provides a structured way to assign permissions according to a user’s responsibilities.

Instead of giving every user unrestricted administrative access, RBAC allows organizations to create roles with specific capabilities and assign those roles to appropriate users.

This makes RBAC one of the most important components of a mature Wazuh access control architecture.

For the complete implementation procedure, see our How to Configure Wazuh RBAC guide.

What Wazuh RBAC Is

RBAC is an authorization model in which permissions are associated with roles, and users are associated with those roles.

Instead of thinking:

User A → Permission 1
User A → Permission 2
User A → Permission 3

the organization can define:

Analyst Role
   ├── Permission 1
   ├── Permission 2
   └── Permission 3

User A → Analyst Role

This makes the access model easier to administer and audit.

Wazuh provides RBAC for controlling access to Wazuh server API resources according to user privileges.

Understanding Roles and Permissions

A role represents a collection of permissions associated with a particular responsibility.

Permissions determine which actions a role can perform against specific resources.

For example, an analyst role might be permitted to retrieve alert information but denied access to user-management operations.

The fundamental relationship is:

User
  |
  v
Role
  |
  v
Permissions
  |
  v
Resources / Actions

A good RBAC design should avoid granting permissions simply because they are convenient.

Each permission should have an operational justification.

View Existing Wazuh Roles

Before creating custom roles, administrators should inspect the roles that already exist.

This helps answer:

• Which roles are available?
• What permissions do they contain?
• Which users are associated with them?
• Which roles are appropriate as starting points?
• Are custom roles actually necessary?

Understanding the existing authorization model also reduces the risk of creating redundant or conflicting roles.

Administrators should document the existing roles before making substantial changes, especially in production environments.

Create Custom Security Roles

Custom roles are useful when built-in permissions do not precisely match an organization’s responsibilities.

For example, an enterprise SOC might require:

wazuh_security_admin
wazuh_soc_analyst
wazuh_incident_responder
wazuh_security_auditor

Each role can be designed around a specific operational function.

The goal should not be to create as many roles as possible.

Instead, create roles when there is a meaningful difference in required access.

A role that grants exactly the permissions required by a specific responsibility is generally easier to understand and audit than a collection of highly overlapping roles.

Assign Permissions Using Least Privilege

The safest RBAC implementation starts with the minimum permissions necessary and expands access only when there is a documented operational requirement.

For example, an analyst who only investigates alerts does not necessarily need permissions to:

• Create users
• Delete users
• Modify roles
• Change authentication configuration
• Modify index security
• Manage Wazuh infrastructure

A responder may need additional operational permissions, but those should still be limited to the actions required by the incident-response workflow.

Least privilege should therefore be applied at both the role level and the resource level.

Map Users to Roles

After creating roles, administrators need to associate users with those roles.

Also, for local users, this can be managed directly through Wazuh’s user-management mechanisms.

For enterprise SSO, role mappings can connect external groups or identity attributes to Wazuh roles.

For example:

SOC-Admins       → wazuh_security_admin
SOC-Analysts     → wazuh_soc_analyst
SOC-Responders   → wazuh_incident_responder
SOC-Auditors     → wazuh_security_auditor

This approach is particularly valuable because group membership can become the authoritative source for role assignment.

Configure Administrator, Analyst, Responder, and Auditor Roles

A practical enterprise Wazuh deployment can separate responsibilities into four primary roles.

Administrator Role

Administrators require broad privileges because they maintain the Wazuh platform.

Typical responsibilities include:

• Managing users
• Managing roles
• Managing authentication
• Managing Wazuh configuration
• Managing agents
• Managing integrations
• Managing security settings
• Troubleshooting platform infrastructure

Because this role is highly privileged, it should be assigned to as few accounts as practical.

Analyst Role

Analysts primarily investigate security information.

Their access may include:

• Viewing alerts
• Searching events
• Reviewing endpoint activity
• Investigating vulnerabilities
• Reviewing compliance information
• Accessing assigned dashboards and tenants

They generally do not require unrestricted platform-administration permissions.

Incident Responder Role

Responders require broader operational capabilities than standard analysts.

Depending on the organization’s procedures, they may need permissions associated with:

• Investigating affected endpoints
• Managing specific agent operations
• Performing approved response activities
• Reviewing detailed event information
• Accessing additional security data

Response privileges should remain tightly controlled because incident-response functionality can have operational consequences.

Auditor Role

Auditors typically require read-only visibility.

Their access might include:

• Reviewing security events
• Reviewing audit information
• Reviewing compliance results
• Accessing approved reports
• Inspecting configuration evidence

They should generally not be able to modify users, roles, configurations, agents, or security policies.

Configure RBAC Through the Wazuh Dashboard

The Dashboard provides a graphical interface for managing many Wazuh security settings.

This makes it convenient for administrators who need to:

• Review users
• Review roles
• Configure role mappings
• Manage security configuration
• Validate access assignments

Dashboard-based configuration can reduce configuration errors because administrators can work through structured interfaces instead of manually editing multiple configuration files.

However, changes should still be documented and tested.

For larger deployments, administrators should also understand the underlying API and configuration mechanisms so that RBAC changes can be automated and recovered.

Configure RBAC Through Configuration Files and APIs

Wazuh also provides programmatic mechanisms for managing RBAC.

The Wazuh server API exposes RBAC-related operations, allowing administrators and automation systems to manage users, roles, and associated security policies.

This can be particularly useful for:

• Infrastructure-as-code workflows
• Automated deployments
• Configuration management
• Disaster recovery
• Reproducible security configurations
• Automated testing

Configuration files and APIs should be changed carefully in production.

A syntactically valid configuration can still produce an authorization policy that is operationally incorrect.

For that reason, RBAC changes should ideally be version-controlled, reviewed, tested, and documented.

Test Role Permissions

Never assume that an RBAC configuration works simply because the configuration was accepted.

Test each role using a dedicated test account.

For example:

The exact permissions should match the organization’s security policy.

Testing should include both allowed and denied operations.

A good access-control test does not merely confirm that users can do what they need.

It also confirms that they cannot perform actions outside their responsibilities.

Troubleshoot Permission-Denied Errors

Permission-denied errors commonly occur when:

• A role is missing a required permission
• A role mapping is incorrect
• The wrong backend role is being supplied
• A user has not received the expected role
• A tenant restriction blocks access
• An index permission is missing
• Document-level restrictions exclude the requested data
• Field-level security removes expected fields
• The request is being made through a different interface with different authorization requirements

When troubleshooting, start by identifying the identity and then work through the authorization chain:

Authenticated User
       ↓
Backend / Group Roles
       ↓
Role Mapping
       ↓
Effective Roles
       ↓
Permissions
       ↓
Tenant
       ↓
Index / Document / Field Restrictions
       ↓
Requested Resource

This prevents administrators from randomly changing permissions until the error disappears.

For a dedicated troubleshooting workflow: Troubleshooting Wazuh RBAC.

Configure Wazuh Multi-Tenancy

RBAC answers an important question:

“What is this user allowed to do?”

Multi-tenancy addresses a different question:

“Which security data should this user be able to access?”

This distinction makes multi-tenancy an important complement to RBAC.

A user can have permission to investigate alerts while still being restricted to the security data belonging to their assigned team, environment, or tenant.

What Wazuh Multi-Tenancy Means

Wazuh multi-tenancy allows security data and Dashboard access to be logically separated between different groups of users.

For example, an organization might use separate tenants for:

• Corporate security
• Cloud security
• Infrastructure security
• Compliance
• Development environments
• Production environments
• Different customers in a managed security service

This prevents users from automatically receiving unrestricted visibility across the entire Wazuh environment.

Multi-tenancy therefore provides an additional data-isolation layer on top of authorization.

Tenants vs Roles

Roles and tenants should not be treated as interchangeable.

A role primarily determines what actions a user can perform.

A tenant determines which security-data space the user can access.

Consider this example:

User: Alice
Role: SOC Analyst
Tenant: Production

User: Bob
Role: SOC Analyst
Tenant: Development

Alice and Bob could have essentially identical analyst permissions.

However, Alice works with production security data while Bob works with development data.

This creates a useful separation:

Role
  ↓
What can I do?

Tenant
  ↓
Where can I do it?

Combining both mechanisms provides significantly more granular access control than relying on either mechanism alone.

When to Use Multi-Tenancy

Multi-tenancy is most valuable when different groups need different security-data boundaries.

Consider implementing it when:

• Multiple SOC teams share one Wazuh deployment.
• Different business units require separate visibility.
• A managed security provider supports multiple customers.
• Development and production environments must be isolated.
• Compliance teams require controlled access.
• External analysts require restricted visibility.
• Different geographic teams should see different datasets.

It may be unnecessary for a small Wazuh installation where every authorized user legitimately needs access to the same security data.

Create and Configure Tenants

Tenant configuration should begin with a clear definition of the data boundaries the organization needs.

For example:

Tenant: SOC-Production
Tenant: SOC-Development
Tenant: Compliance
Tenant: Customer-A
Tenant: Customer-B

Each tenant should have a documented purpose and an identified owner.

Avoid creating tenants simply because the feature exists.

Excessive fragmentation can make the environment difficult to administer and can increase the complexity of role mappings, dashboards, and user workflows.

Assign Users to Tenants

After creating tenants, users or groups must be granted access to the appropriate tenant.

A common enterprise model is:

SOC-Production-Analysts
        |
        +---- Analyst Role
        |
        +---- Production Tenant

SOC-Development-Analysts
        |
        +---- Analyst Role
        |
        +---- Development Tenant

Compliance-Team
        |
        +---- Auditor Role
        |
        +---- Compliance Tenant

This demonstrates why RBAC and multi-tenancy work together.

The analyst role determines the user’s operational capabilities, while the tenant determines which security-data environment the analyst can work within.

Isolate Security Data Between Teams

Tenant isolation should be tested as a security boundary rather than assumed to work because users have different tenant assignments.

For example, if a production analyst attempts to access development security data, the request should be denied.

Likewise, an auditor assigned to a compliance tenant should not automatically gain access to unrelated operational data.

The objective is:

Production Analyst
       |
       +---- Production Data ✓
       |
       +---- Development Data ✗
       |
       +---- Customer Data ✗

This is especially important for managed security service providers and large enterprises where security telemetry may contain confidential customer or business-unit information.

Configure Tenant Access for SOC Teams

A practical enterprise configuration could look like this:

The important design principle is to avoid giving users access to more tenants than their responsibilities require.

Administrators may require broad visibility for operational reasons, but ordinary users should generally receive the narrowest practical tenant assignment.

Test Tenant Isolation

Tenant testing should use dedicated accounts representing each major user type.

For example:

Production analyst

• Can access production alerts.
• Can search production security data.
• Cannot access development data.
• Cannot access another customer’s data.

Development analyst

• Can access development data.
• Cannot access production data.

Compliance auditor

• Can access compliance information.
• Cannot modify security configuration.
• Cannot access unrelated operational tenants unless explicitly authorized.

Testing should include both Dashboard and API access where applicable.

A user should not be considered properly isolated if the Dashboard hides a dataset but an alternate API path exposes it.

Common Multi-Tenancy Configuration Problems

Multi-tenancy problems often originate from incorrect role mappings or index permissions rather than from the tenant itself.

Common issues include:

Users can see the wrong tenant

This may indicate incorrect role mappings or overly broad tenant permissions.

Users cannot access their assigned tenant

The user may have been assigned a role without the corresponding tenant access.

Tenant appears in the Dashboard but contains no data

This can occur when the user can enter the tenant but lacks appropriate permissions to access the underlying indexes.

Users can access multiple tenants unexpectedly

Review effective roles and backend-role mappings rather than checking only the user’s visible role.

SSO users receive incorrect tenant access

The identity provider may be sending unexpected group or role attributes.

Role changes do not produce the expected result

Users may need to sign out and establish a new authenticated session before changes become visible.

Field-level restrictions hide expected information

Tenant access and field-level security operate at different layers. A user can have legitimate tenant access while still having specific fields restricted.

For a complete implementation and troubleshooting workflow: How to Set Up Wazuh Multi-Tenancy

The most secure architecture combines multi-tenancy with RBAC rather than treating either feature as a complete access-control solution:

Authentication
      ↓
Identity / Group
      ↓
Role Mapping
      ↓
RBAC Permissions
      ↓
Tenant Access
      ↓
Document-Level Restrictions
      ↓
Field-Level Restrictions
      ↓
Audit Logging

This layered architecture allows an enterprise SOC to control both what users can do and which security information they can access, providing a much stronger foundation for Wazuh access control.

Configure Wazuh Field-Level Security

RBAC and multi-tenancy provide important access boundaries, but some organizations require even more granular control over security data.

A user may legitimately need access to a Wazuh alert while still being prohibited from viewing certain fields within that alert.

Field-level security (FLS) addresses this requirement by controlling which fields a user is allowed to see.

This makes field-level security an important component of a defense-in-depth Wazuh access control strategy.

Related Guide: How to Configure Wazuh Field Level Security

What Field-Level Security Means

Field-level security restricts access to individual fields within documents stored in the Wazuh indexer.

Instead of blocking an entire security event, administrators can allow a user to access the document while limiting the information exposed within it.

Conceptually:

Wazuh Alert
├── timestamp          ✓
├── agent.name         ✓
├── rule.description   ✓
├── rule.level         ✓
├── source.ip          ✓
├── user.name          ✗
└── sensitive.field    ✗

The user can still investigate the event, but selected information is hidden.

This is useful when security data contains information that should not be broadly exposed.

Field-Level vs Document-Level Security

Field-level security and document-level security solve different problems.

Document-level security (DLS) determines which documents a user can access.

Field-level security (FLS) determines which fields within those accessible documents the user can see.

For example:

Document-Level Security
        ↓
Which alerts can I access?
        ↓
Alert A ✓
Alert B ✓
Alert C ✗
        ↓
Field-Level Security
        ↓
Which fields can I see?
        ↓
Alert A
├── agent.name ✓
├── rule.description ✓
├── source.ip ✓
└── sensitive_field ✗

These controls can be combined.

A user could therefore be restricted to alerts belonging to a specific tenant while also having selected fields removed from those alerts.

When to Restrict Individual Wazuh Fields

Field-level restrictions are appropriate when an organization needs to expose security information without exposing every attribute associated with it.

Potential examples include:

• Personally identifiable information
• Sensitive usernames
• Internal application metadata
• Confidential business information
• Customer-specific information
• Infrastructure details
• Fields containing sensitive identifiers
• Information subject to internal security policies

The decision should be based on the sensitivity of the data and the user’s responsibilities.

Do not automatically restrict fields simply because they contain potentially sensitive information.

Security analysts may legitimately require detailed fields to investigate incidents.

The objective is least-privilege visibility, not maximum data concealment.

Protect Sensitive Alert Fields

Before implementing FLS, identify which fields actually require protection.

Start by examining representative Wazuh alerts and identifying fields that contain sensitive information.

For example:

{
  "agent": {
    "name": "server-01"
  },
  "rule": {
    "description": "Successful authentication"
  },
  "data": {
    "user": "alice",
    "department": "finance"
  }
}

An organization might decide that analysts can see the agent and rule information but that certain business-related fields should only be available to authorized users.

This should be documented as a data-classification decision rather than an arbitrary technical restriction.

Configure Field-Level Permissions

Field-level permissions are configured through the Wazuh indexer’s security controls.

The administrator first determines:

1. Which role requires restricted visibility.
2. Which indexes contain the relevant data.
3. Which fields should be accessible.
4. Whether the policy should use an allowlist or denylist approach.
5. Whether document-level restrictions must also be applied.
6. How the resulting policy will be tested.

A simplified conceptual model looks like:

Role: Restricted Analyst
        |
        v
Index Permission
        |
        +---- Document Restrictions
        |
        +---- Field Restrictions
        |
        v
Effective Data Visibility

The exact index patterns and security configuration depend on the Wazuh version and deployment architecture.

For current implementation syntax, always validate the configuration against the applicable Wazuh and Wazuh Indexer documentation.

Combine Field-Level Security With RBAC

FLS should not replace RBAC.

Instead, the two mechanisms should work together.

RBAC answers:

“What can this user do?”

Field-level security answers:

“What information can this user see?”

For example:

SOC Analyst
     |
     +---- Analyst Role
     |        |
     |        +---- Search Alerts
     |        +---- View Events
     |
     +---- Production Tenant
     |
     +---- Field-Level Restrictions
              |
              +---- Sensitive Field ✗

This layered model provides significantly more control than assigning a single broad role.

Test Restricted Fields

Field-level security should always be tested using a dedicated test account.

The test should verify both positive and negative cases.

For example:

Testing should be performed from the perspective of the actual user role rather than an administrator.

An administrator may be able to see information that a restricted analyst cannot, making administrative testing an unreliable way to validate FLS.

Troubleshoot Field-Level Access Problems

Field-level security problems commonly appear as missing fields, incomplete search results, unexpected authorization errors, or dashboards that behave differently for different users.

When troubleshooting, check the authorization chain systematically:

User
 ↓
Role Mapping
 ↓
Effective Role
 ↓
Index Permission
 ↓
Document-Level Security
 ↓
Field-Level Security
 ↓
Dashboard / Query

Common causes include:

• The wrong role is assigned.
• The expected role mapping is not being applied.
• The user has multiple roles with unexpected effective permissions.
• The wrong index pattern is being used.
• A field restriction is applied to a broader index than intended.
• Document-level restrictions exclude the expected data.
• Dashboard queries depend on fields that have been restricted.
• A security configuration change has not been loaded as expected.
• The user is testing with an administrator account.

When troubleshooting, compare the user’s effective permissions against a known-good role rather than immediately broadening permissions.

Configure Wazuh Audit Logs

Access control without auditing creates a significant visibility gap.

It is not enough to determine who is allowed to access Wazuh.

Security teams also need to know who actually accessed the platform, what actions they attempted, which actions failed, and what security configuration changed.

Audit logging provides this accountability layer.

Related Guide: How to Configure Wazuh Audit Logs

Why Access-Control Auditing Matters

Access-control auditing serves several purposes.

It helps security teams:

• Investigate suspicious authentication
• Identify compromised accounts
• Detect privilege escalation
• Track administrator activity
• Investigate unauthorized access attempts
• Demonstrate compliance
• Reconstruct security incidents
• Validate access-control policies

For example, if an analyst account suddenly begins generating repeated authorization failures followed by successful administrative operations, those events deserve investigation.

Audit logs can provide the timeline necessary to determine what happened.

NIST SP 800-53 identifies audit and accountability as a core security-control family and includes requirements for generating, reviewing, protecting, and retaining audit records.

What Wazuh Audit Logs Record

The exact events available depend on the Wazuh component and configuration, but access-control auditing should provide visibility into activities such as:

• Authentication attempts
• Authentication failures
• Successful administrator authentication
• Authorization failures
• User creation
• User deletion
• Role creation
• Role modification
• Permission changes
• Role mappings
• Security configuration changes
• Administrative API activity
• Other security-relevant configuration changes

The objective is to create enough information to answer:

Who performed the action, when did they perform it, what did they attempt to do, and was the action successful?

Monitor Authentication Events

Authentication events should be monitored continuously.

Security teams should look for patterns such as:

• Repeated failed logins
• Authentication attempts from unusual locations
• Authentication outside normal operating hours
• Successful logins following many failures
• Sudden administrative logins
• Login attempts against disabled accounts
• Authentication activity from unexpected networks

A single failed login is usually not significant.

A pattern of hundreds of failed attempts against an administrator account is considerably more concerning.

Wazuh itself can be used to collect and analyze authentication events, allowing access-control monitoring to become part of the same security-monitoring pipeline.

Monitor Authorization Failures

Authentication failures and authorization failures indicate different problems.

An authentication failure means the identity could not be successfully authenticated.

An authorization failure generally means the identity was recognized but did not have permission to perform the requested operation.

Repeated authorization failures can indicate:

• Misconfigured RBAC
• Incorrect role mappings
• An improperly configured application
• A user attempting to access restricted resources
• Privilege escalation attempts
• Compromised credentials

For this reason, repeated 403 responses or equivalent permission-denied events should not automatically be dismissed as configuration problems.

They can also be useful security signals.

Track Administrative Changes

Administrative changes should receive heightened monitoring because they can alter the security posture of the entire Wazuh deployment.

Examples include:

• Creating administrative accounts
• Deleting accounts
• Changing administrator roles
• Modifying authentication configuration
• Changing index security policies
• Modifying role mappings
• Changing tenant assignments
• Modifying password policies
• Changing network restrictions

A security team should ideally be able to determine which administrator performed each change.

Track Role and Permission Changes

Role modifications deserve special attention because they can silently increase an account’s capabilities.

For example:

Before:
SOC Analyst
  ↓
Read Security Alerts

After:
SOC Analyst
  ↓
Read Security Alerts
  ↓
Manage Agents
  ↓
Manage Users
  ↓
Modify Roles

A change like this should be deliberate, documented, and attributable to a specific administrator.

Unexpected privilege expansion is a valuable indicator of potential account compromise or insider misuse.

Detect Suspicious Account Activity

Access-control auditing becomes particularly powerful when events are correlated.

Consider the following sequence:

1. Multiple failed administrator logins
             ↓
2. Successful administrator authentication
             ↓
3. Role modification
             ↓
4. New privileged account created
             ↓
5. Configuration changed

Each event might appear relatively ordinary in isolation.

Together, they represent a potentially serious security incident.

Organizations should therefore create detections for suspicious combinations of authentication, authorization, and administrative events.

Forward Access-Control Events to Security Monitoring

Access-control logs should not exist only as isolated records that nobody reviews.

Relevant events should be incorporated into the organization’s security-monitoring workflow.

Wazuh can analyze logs from operating systems, applications, authentication systems, and infrastructure, allowing organizations to correlate Wazuh access-control activity with broader security events.

For example, a suspicious Wazuh administrator login could be correlated with:

• VPN authentication
• Endpoint activity
• Firewall events
• Identity-provider logs
• Privileged-access-management events
• Cloud authentication
• Network activity

This produces much stronger detection than examining Wazuh authentication logs independently.

Establish an Audit-Retention Strategy

Audit retention should be based on organizational requirements, regulatory obligations, incident-response needs, and available storage.

A retention policy should define:

• Which access-control events are retained
• How long they are retained
• Where they are stored
• Who can access them
• How they are protected
• Whether they are backed up
• How they are deleted after the retention period

Security audit data should also be protected against unauthorized modification.

If an attacker compromises an administrative account, allowing that same account unrestricted ability to modify or delete its own audit trail creates a serious forensic weakness.

A stronger design separates the systems responsible for generating, storing, and reviewing critical audit evidence wherever practical.

Configure the Wazuh Password Policy

Authentication security begins with identity verification, but local Wazuh accounts also require controls that protect credentials from guessing, reuse, and compromise.

A properly designed password policy establishes minimum requirements for local credentials and helps reduce the likelihood that an attacker can compromise a privileged Wazuh account through password-based attacks.

Related Guide: How to Configure Wazuh Password Policy

Why Password Policies Matter

Weak passwords can undermine otherwise sophisticated access-control architecture.

An organization may have carefully designed:

• RBAC
• Multi-tenancy
• Field-level security
• Audit logging
• Network restrictions

but a compromised administrator password can still provide an attacker with a valid identity.

Password policies therefore form one layer of the authentication security model.

They should be combined with stronger controls such as MFA and enterprise SSO where supported and appropriate.

Configure Minimum Password Length

Password length is one of the most important characteristics of password security.

Longer passwords generally increase the difficulty of guessing or brute-forcing credentials.

Organizations should establish a minimum password length appropriate to their risk profile and authentication architecture.

For privileged Wazuh accounts, stronger requirements are appropriate because compromise can have a significantly larger impact.

A password policy should also avoid relying exclusively on arbitrary complexity requirements while allowing very short passwords.

Length, uniqueness, resistance to guessing, and protection against reuse should be considered together.

Configure Password Complexity

Password-complexity requirements can require combinations of:

• Uppercase characters
• Lowercase characters
• Numbers
• Special characters

However, complexity rules should be implemented carefully.

A requirement such as “one uppercase, one number, and one symbol” does not automatically produce a secure password if users choose predictable patterns.

Modern password policy design should therefore prioritize sufficiently long, unique credentials and protection against commonly compromised passwords.

Configure Password Expiration

Password expiration controls determine how frequently users must change their credentials.

Organizations should establish expiration requirements based on their security policy and risk environment.

Privileged accounts may require additional controls compared with ordinary accounts.

However, forced periodic password changes should not be treated as a substitute for:

• MFA
• Account monitoring
• Password screening
• Credential compromise detection
• Strong authentication
• Rapid account disabling

Password expiration is only one part of credential lifecycle management.

Configure Password History

Password-history controls prevent users from repeatedly cycling between a small set of previously used passwords.

For example:

Password A
   ↓
Password B
   ↓
Password A  ✗

The goal is to prevent users from immediately reverting to a previously compromised or weak credential.

Password history is especially useful for privileged accounts that control access to sensitive security infrastructure.

Configure Failed-Login Protections

Repeated failed authentication attempts should trigger protective controls appropriate to the deployment.

Potential protections include:

• Account lockout
• Temporary authentication delays
• Login throttling
• Monitoring
• Alerting
• IP-based restrictions
• MFA
• Automated response

These controls reduce the effectiveness of password-guessing and brute-force attacks.

However, lockout policies should be designed carefully.

An overly aggressive lockout mechanism can itself become a denial-of-service vector if an attacker intentionally triggers repeated failures against legitimate accounts.

Protect Privileged Accounts

Wazuh administrator accounts deserve stronger protection than ordinary accounts.

Recommended controls include:

• Use dedicated administrator identities.
• Avoid sharing administrative accounts.
• Minimize the number of administrators.
• Require strong authentication.
• Use MFA through an appropriate identity provider where possible.
• Restrict administrative access by network.
• Monitor administrator logins.
• Monitor privilege changes.
• Review administrator membership regularly.
• Maintain a controlled emergency-access account.

Administrative accounts should also be used only for administrative work.

An administrator should not routinely use a highly privileged identity for ordinary browsing or unrelated activities.

Password Policies for API Users

API credentials deserve the same security attention as interactive accounts.

An API identity can potentially perform powerful operations without a human interacting with the Dashboard.

Organizations should therefore:

• Avoid sharing API credentials.
• Give API identities only the required permissions.
• Rotate credentials according to policy.
• Remove unused API identities.
• Monitor API authentication.
• Restrict API access by network where possible.
• Avoid embedding privileged credentials directly in source code.
• Review API permissions periodically.

The principle of least privilege applies equally to machine identities and human users.

An automation script that only needs read access should not receive an administrator-level API identity.

Password Policies With SSO

When Wazuh authentication is delegated to an external identity provider, password policy enforcement may occur outside Wazuh.

For example:

User
  ↓
Enterprise Identity Provider
  ↓
Password Policy
  ↓
MFA / Conditional Access
  ↓
Wazuh
  ↓
Role Mapping
  ↓
Wazuh Permissions

In this architecture, the identity provider becomes responsible for the user’s primary authentication policy, while Wazuh remains responsible for mapping the authenticated identity to appropriate authorization policies.

This is one reason enterprise deployments often benefit from centralized identity management.

It prevents each application from independently implementing password, account lifecycle, and authentication policies.

For organizations integrating SSO, see:

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

Test Password-Policy Enforcement

After configuring a password policy, test each requirement explicitly.

A controlled test should verify:

• Passwords below the minimum length are rejected.
• Weak passwords are rejected when complexity requirements apply.
• Previously used passwords are rejected when history is enabled.
• Expired passwords trigger the expected behavior.
• Repeated failed logins trigger the configured protection.
• Administrator accounts receive the intended policy.
• API identities remain operational while following the organization’s credential requirements.
• SSO users follow the identity provider’s authentication policy.

Testing should be performed using non-production accounts where possible.

The goal is to verify both security enforcement and operational usability.

A password policy that is technically secure but prevents legitimate administrators from recovering access during an emergency can create its own operational risk.

The strongest Wazuh authentication architecture combines secure local credentials where necessary, centralized SSO where appropriate, least-privilege authorization, strong network restrictions, continuous auditing, and regular access reviews.

Together, these controls form a layered identity-security model:

Strong Authentication
        ↓
SSO / Local Identity
        ↓
Role Mapping
        ↓
RBAC
        ↓
Tenant Isolation
        ↓
Field / Document Security
        ↓
Network Restrictions
        ↓
Audit Logging
        ↓
Continuous Access Review

This layered model is the foundation of an enterprise-ready Wazuh access-control strategy.

Wazuh Access Control Best Practices

A well-designed Wazuh access-control architecture should follow the principle of least privilege, ensuring that every user, service account, and administrator receives only the permissions required to perform their responsibilities.

Avoid treating Wazuh access control as a one-time configuration.

Roles, permissions, network restrictions, authentication policies, and user memberships should be reviewed continuously as the environment changes.

Follow Least-Privilege Principles

Grant users the minimum permissions necessary to perform their jobs.

Avoid assigning broad administrator privileges simply because they are convenient.

For example, a security analyst who only needs to investigate alerts should not automatically receive permissions to modify Wazuh configuration, manage users, or change security policies.

A least-privilege implementation should:

• Start with the minimum required permissions.
• Add permissions only when there is a documented requirement.
• Avoid giving users administrator roles by default.
• Separate read, write, and administrative capabilities where appropriate.
• Review elevated permissions periodically.
• Remove permissions when responsibilities change.

Least privilege reduces the potential impact of compromised accounts and accidental configuration changes.

Use Dedicated Roles for Different SOC Responsibilities

Create roles that correspond to actual responsibilities within the security operations center rather than creating a single role for every user.

A typical SOC might use roles such as:

Custom roles make the access model easier to understand, review, and maintain.

Separate Administrators from Analysts

Security administrators and analysts have fundamentally different responsibilities.

Administrators may need to manage users, roles, authentication, Wazuh configuration, and security settings.

Analysts generally need to investigate alerts and security events without modifying the underlying platform.

Keeping these responsibilities separate reduces the risk that an analyst accidentally changes a critical security configuration.

It also limits the consequences of a compromised analyst account.

Separate Responders from Auditors

Incident responders require operational capabilities that auditors generally should not have.

Conversely, auditors typically need broad visibility into security activity without the ability to modify configurations or respond to incidents.

Use separate roles so that:

• Responders can perform approved operational tasks.
• Auditors can review relevant data.
• Auditors cannot modify security configurations.
• Responders cannot automatically inherit administrative privileges they do not require.

This separation creates a stronger division of duties.

Minimize the Use of Administrator Privileges

Administrator privileges should be reserved for users who actually manage the Wazuh environment.

Avoid using administrator accounts for routine alert investigation or monitoring.

When possible, administrators should use lower-privileged accounts for ordinary activities and reserve privileged accounts for administrative operations.

You should also periodically identify:

• Users with administrator roles.
• Shared administrator accounts.
• Unused privileged accounts.
• Service accounts with excessive permissions.
• Roles containing unnecessary administrative privileges.

Use Multi-Tenancy for Organizational Isolation

Multi-tenancy can provide an additional layer of isolation when multiple teams, departments, customers, or environments share the same Wazuh deployment.

For example, an organization could separate:

• Corporate security operations.
• Cloud security.
• Compliance teams.
• Regional SOC teams.
• Managed security customers.

Users should only be assigned to the tenants containing the data they are authorized to access.

Multi-tenancy should complement RBAC rather than replace it. RBAC controls what users can do, while tenant configuration can help control which security data they can access.

Restrict Sensitive Fields

Not every user who can view an alert necessarily needs access to every field within that alert.

Field-level security can help protect sensitive information such as:

• Internal infrastructure details.
• User information.
• Host metadata.
• Application-specific data.
• Sensitive event fields.
• Information subject to regulatory or organizational restrictions.

Combine field-level restrictions with RBAC and tenant isolation when a user requires access to security events but should not see specific sensitive fields.

Enforce Strong Password Policies

Local Wazuh accounts should be protected with appropriate password controls.

A strong password policy should address:

• Minimum password length.
• Password complexity.
• Password history.
• Password expiration where appropriate.
• Failed authentication attempts.
• Account lockout or other brute-force protections.
• Privileged account security.

If Wazuh is integrated with an external identity provider, apply appropriate authentication controls within that identity provider as well.

Related Guide: How to Configure Wazuh Password Policy

Restrict Administrative Interfaces by Network

Authentication should not be the only protection for administrative interfaces.

Use network-level controls to restrict access to sensitive Wazuh services.

For example, Wazuh Dashboard and API access can be limited to trusted administrative networks, VPNs, management subnets, or other approved sources.

A defense-in-depth approach can combine:

1. Network restrictions.
2. TLS encryption.
3. Strong authentication.
4. RBAC.
5. Multi-tenancy.
6. Audit logging.

This means an attacker must bypass multiple independent controls rather than relying on a single authentication mechanism.

Enable Comprehensive Audit Logging

Access-control changes and authentication activity should be auditable.

Monitor events such as:

• Successful authentication.
• Failed authentication.
• Account changes.
• Role changes.
• Permission changes.
• Tenant assignments.
• Administrative configuration changes.
• Authorization failures.

Send relevant audit events into your security monitoring workflow so suspicious access-control activity can generate alerts.

Related guide: How to Configure Wazuh Audit Logs

Review Permissions Regularly

Access reviews should be performed on a scheduled basis rather than only after security incidents.

During each review, examine:

• User accounts.
• Assigned roles.
• Role permissions.
• Tenant memberships.
• Privileged accounts.
• Service accounts.
• Inactive accounts.
• Recently modified permissions.

Compare actual permissions against each user’s current responsibilities.

Remove Inactive Users and Obsolete Roles

Old accounts and unused roles increase the attack surface of the Wazuh environment.

When employees leave the organization or change responsibilities, remove or modify their Wazuh access promptly.

Likewise, remove obsolete custom roles instead of allowing unused permissions to accumulate.

A useful lifecycle is:

Create → Assign → Review → Modify → Revoke

Back Up Access-Control Configurations

Access-control configuration should be included in the Wazuh disaster-recovery strategy.

Maintain protected backups of important RBAC configuration, role mappings, and related security settings.

Store backups separately from the production Wazuh environment and protect them from unauthorized modification.

Automated backups are preferable because they reduce the possibility of losing access-control configuration during a cluster failure or administrative mistake.

Related guide: How to Backup Wazuh RBAC Configurations

Test Disaster-Recovery Procedures

A backup is only useful if it can actually be restored.

Periodically perform recovery tests in an isolated environment.

Verify that restored users, roles, mappings, tenants, and permissions behave as expected.

Document:

• What is backed up.
• Where backups are stored.
• Who can restore them.
• How restoration is performed.
• How restored permissions are validated.
• What to do if the primary backup is unavailable.

Document Access-Control Changes

Maintain an audit trail for significant access-control changes.

Documentation should identify:

• What changed.
• Why it changed.
• Who approved the change.
• Who implemented it.
• When it was implemented.
• Which users or roles were affected.
• How the change was tested.

This is particularly important in regulated environments where organizations must demonstrate control over privileged access.

Real-World Wazuh Access Control Example

Consider an enterprise SOC operating a centralized Wazuh deployment that monitors Linux and Windows servers, cloud workloads, network infrastructure, and critical applications.

The organization has four primary security teams:

• Security administrators manage the Wazuh platform.
• Security analysts investigate alerts and security events.
• Incident responders investigate and respond to confirmed incidents.
• Auditors review security activity and access-control records.

The organization uses RBAC, multi-tenancy, field-level security, authentication policies, network restrictions, and audit logging as complementary controls.

Separate Security Administrators, Analysts, Responders, and Auditors

The organization creates separate Wazuh roles instead of assigning every SOC employee the administrator role.

The resulting access model might look like this:

This prevents routine users from inheriting unnecessary administrative privileges.

Create Dedicated RBAC Roles

The Wazuh administrators create dedicated roles for each SOC function.

For example:

SOC Analyst

• View relevant alerts.
• Search security events.
• Investigate affected endpoints.
• Access approved dashboards.
• Cannot modify core Wazuh security configuration.

Incident Responder

• Perform the same investigation activities as analysts.
• Access additional operational capabilities required for incident response.
• Modify or execute approved response-related operations.

Security Administrator

• Manage users.
• Manage roles.
• Configure security settings.
• Maintain Wazuh infrastructure.
• Perform administrative operations.

Auditor

• Review security activity.
• Review audit information.
• Access approved security data.
• Cannot modify Wazuh configuration or user permissions.

Restrict Analysts to Appropriate Security Data

Analysts should only have access to the data required for their assigned responsibilities.

For example, analysts responsible for corporate endpoints may receive access to corporate endpoint data without receiving access to restricted compliance or executive environments.

This can be implemented through an appropriate combination of RBAC permissions, tenant isolation, and data-access controls.

Give Responders Additional Operational Permissions

Incident responders need more capabilities than ordinary analysts.

For example, a responder may need to investigate an endpoint and perform approved containment or response operations.

However, these permissions should be explicitly assigned rather than inherited from the administrator role.

This creates a controlled privilege boundary:

Analyst → Responder → Administrator

Each step provides additional capabilities without automatically granting the highest level of access.

Give Administrators Full Management Privileges

Only a small group of trusted administrators receives full management access.

Administrators are responsible for:

• User management.
• RBAC configuration.
• Security configuration.
• Wazuh infrastructure.
• Authentication integration.
• Access-control policies.
• Backup and recovery.

Administrative accounts are protected with stronger authentication and restricted network access.

Isolate Teams Using Multi-Tenancy

The organization uses Wazuh multi-tenancy to separate security data between teams.

For example:

• Corporate SOC → Corporate tenant.
• Cloud security → Cloud tenant.
• Compliance → Compliance tenant.
• Managed customers → Customer-specific tenants.

Users receive access only to the tenants relevant to their responsibilities.

This provides an additional data-isolation layer on top of role-based permissions.

Restrict Sensitive Fields with Field-Level Security

Some security events contain information that should not be visible to every user.

The organization therefore applies field-level security to selected sensitive fields.

Analysts can investigate alerts while restricted information remains unavailable to users who do not require it.

Administrators and specifically authorized users retain access where operationally necessary.

Enforce Password and Authentication Policies

Local accounts are protected with an appropriate password policy, while privileged users are subject to stronger authentication requirements.

The organization also integrates Wazuh with its enterprise identity infrastructure where appropriate, allowing centralized authentication and account lifecycle management.

Authentication and authorization remain separate controls: successfully authenticating does not automatically grant access to Wazuh resources.

Restrict Dashboard and API Access by IP

The Wazuh Dashboard and API are accessible only from approved management networks.

For example:

SOC Management Network
        |
        v
   Firewall / ACL
        |
        +----> Wazuh Dashboard
        |
        +----> Wazuh API

Users connecting from unauthorized networks are blocked before they can reach the administrative interfaces.

This provides an additional security layer if an account credential is compromised.

Enable Audit Logging

The organization records authentication, authorization, administrative, and access-control activity.

Security administrators periodically review these events for:

• Failed login attempts.
• Unexpected administrative activity.
• Role modifications.
• Privilege changes.
• Unusual access patterns.
• Unauthorized access attempts.

High-risk events are forwarded into the organization’s broader security monitoring workflow.

Schedule RBAC Backups

The organization schedules automated backups of its RBAC and related access-control configuration.

Backups are stored separately from the production Wazuh cluster and protected against unauthorized access or modification.

The backup process is also monitored so that failed backup jobs do not go unnoticed.

Test the Complete Access-Control Architecture

The organization periodically performs access-control tests using representative accounts.

For example:

Analyst test

• Can access authorized security data.
• Cannot modify administrative settings.
• Cannot access restricted tenant data.
• Cannot view protected fields.

Responder test

• Can access analyst functionality.
• Can perform approved response operations.
• Cannot modify unrelated administrative configuration.

Administrator test

• Can manage required security and platform settings.

Auditor test

• Can review required security and audit information.
• Cannot modify users, roles, or security configuration.

Network test

• Authorized management IPs can reach administrative interfaces.
• Unauthorized IPs are blocked.

Recovery test

• Backed-up access-control configuration can be restored successfully.
• Users receive the expected permissions after recovery.

This layered testing validates that the Wazuh access-control architecture works as a complete system rather than merely confirming that individual settings exist.

How to Audit and Maintain Wazuh Access Control

Wazuh access control should be treated as an ongoing security-control lifecycle.

New employees join, existing employees change responsibilities, roles evolve, and security requirements change over time.

Regular reviews help ensure that the permissions configured in Wazuh continue to match the organization’s actual security requirements.

Perform Periodic Access Reviews

Establish a recurring access-review schedule.

During each review, compare Wazuh permissions against current job responsibilities.

Check:

• User accounts.
• Assigned roles.
• Role permissions.
• Tenant memberships.
• Privileged accounts.
• Authentication configuration.
• Network restrictions.
• Field-level restrictions.

A quarterly review may be appropriate for many environments, while highly regulated or high-risk environments may require more frequent reviews.

Review Privileged Accounts

Privileged accounts deserve particular attention because their compromise can affect the entire Wazuh deployment.

Create an inventory of users with elevated permissions and verify that each account still requires them.

Look for:

• Former administrators.
• Shared administrator accounts.
• Dormant privileged accounts.
• Excessively broad custom roles.
• Service accounts with unnecessary privileges.

Remove or reduce privileges that are no longer justified.

Audit Role Assignments

Review which users and groups are mapped to each Wazuh role.

Ask:

Does every user assigned to this role still require all of its permissions?

Also inspect custom roles for permission creep.

A role that originally contained five permissions may eventually accumulate additional permissions as administrators respond to user requests.

Periodically comparing each role against its original purpose helps prevent this gradual expansion.

Review Tenant Memberships

Multi-tenancy requires regular membership reviews.

Verify that users can access only the tenants required for their current responsibilities.

When an employee changes teams, update tenant memberships alongside their RBAC assignments.

Tenant reviews should also identify:

• Users with access to multiple unnecessary tenants.
• Empty or obsolete tenants.
• Incorrect group-to-tenant mappings.
• Cross-team access that is no longer required.

Monitor Failed Authentication Attempts

Repeated authentication failures can indicate:

• Brute-force attempts.
• Password spraying.
• Credential stuffing.
• Misconfigured applications.
• Users experiencing authentication problems.

Monitor failed authentication events and establish thresholds for investigation.

Particular attention should be given to repeated failures against privileged accounts.

Monitor Authorization Failures

Authentication failures are not the only useful signal.

Authorization failures can reveal attempts to access resources that a user does not have permission to access.

For example, a compromised analyst account repeatedly attempting to access administrative resources may indicate privilege escalation activity.

Correlate authorization failures with:

• User identity.
• Source IP.
• Requested resource.
• Time of access.
• Existing roles.
• Recent role changes.

Detect Privilege Escalation

Monitor changes that increase a user’s access level.

High-risk events include:

• Assigning administrator roles.
• Adding users to privileged groups.
• Expanding tenant access.
• Granting additional permissions.
• Modifying security-role mappings.

These changes should follow an approval process and generate auditable records.

Unexpected privilege changes should be investigated promptly.

Review Access-Control Changes

Maintain visibility into changes to:

• Users.
• Roles.
• Role mappings.
• Permissions.
• Tenants.
• Authentication settings.
• Network restrictions.
• Field-level security policies.

For important environments, connect configuration changes to a formal change-management process.

A useful record should answer:

Who changed it? What changed? Why was it changed? When was it changed? Who approved it?

Test Security Controls After Wazuh Upgrades

Wazuh upgrades can affect security configuration, authentication, authorization, integrations, and component compatibility.

After an upgrade, verify that critical access-control behavior still works.

Test representative accounts and confirm:

• Authentication works.
• RBAC assignments remain correct.
• Tenant isolation remains effective.
• Restricted fields remain protected.
• Administrative interfaces remain network-restricted.
• Audit logging continues to work.
• SSO mappings still function.
• Privileged permissions have not unexpectedly expanded.

Do not assume that a successful software upgrade automatically means that the security model remains unchanged.

Maintain Wazuh Access-Control Documentation

Maintain current documentation describing the organization’s access-control architecture.

At minimum, document:

• Wazuh roles.
• Role permissions.
• User-to-role mappings.
• Tenant structure.
• Field-level restrictions.
• Authentication methods.
• Network restrictions.
• Privileged accounts.
• Backup procedures.
• Recovery procedures.
• Access-review schedules.
• Change-management requirements.

A documented access-control model makes troubleshooting and audits substantially easier and provides administrators with a clear reference when modifying permissions.

Ultimately, effective Wazuh access control is a layered security model rather than a single feature.

RBAC determines what users can do, multi-tenancy helps isolate the data they can access, field-level security protects sensitive information, authentication policies protect identities, IP restrictions limit network exposure, and audit logging provides visibility into how those controls are being used.

Regular reviews and recovery testing ensure that those controls continue to work as the Wazuh environment evolves.

Configure a Wazuh IP Whitelist

Identity-based access controls are only one layer of a secure Wazuh deployment.

Even a properly authenticated user should not necessarily be able to reach every Wazuh service from every network.

A Wazuh IP whitelist adds a network-level security boundary by restricting connections to trusted IP addresses or CIDR ranges.

This creates an additional layer of defense if credentials are compromised or an administrative interface is accidentally exposed.

Related Guide: How to Configure a Wazuh IP Whitelist

Why Network-Level Access Control Matters

Network-level access controls reduce the number of systems that can communicate with sensitive Wazuh services.

For example, an organization may decide that:

• The Dashboard is accessible only from the SOC network.
• The Wazuh API is accessible only from administrator workstations.
• The Indexer is accessible only by Wazuh components.
• Agent communication is accepted only from approved endpoint networks.
• External administrative access must pass through a VPN or reverse proxy.

This creates defense in depth.

Even if an attacker obtains valid credentials, they may still be unable to reach the protected service from an unauthorized network.

Wazuh’s documentation recommends restricting access to sensitive services such as the indexer using network controls and trusted networks.

Identify Trusted Management Networks

Before creating an allowlist, identify exactly which networks need access.

Typical trusted networks include:

• SOC analyst workstations
• Security administrator networks
• Management VLANs
• VPN address pools
• Bastion hosts
• Automation servers
• Wazuh infrastructure networks

Document these networks before implementing firewall rules.

For example:

SOC Network
192.168.10.0/24

Security Administration
192.168.20.0/24

Wazuh Infrastructure
10.10.50.0/24

VPN Administration
10.20.0.0/24

Do not assume that an entire corporate network needs access simply because a small number of administrators require Wazuh access.

The smaller the trusted network boundary, the smaller the potential attack surface.

Allowlist Administrator IP Addresses

Administrative interfaces should generally have more restrictive network access than ordinary monitoring interfaces.

For example, the organization could restrict administrative access to:

Administrator Workstation A
203.0.113.10

Administrator Workstation B
203.0.113.11

Management VPN
10.20.0.0/24

This can be enforced through host firewalls, network firewalls, security groups, reverse proxies, or other network controls.

Where possible, administrative access should originate from controlled systems rather than arbitrary employee workstations.

Allowlist Trusted Agent Networks

Agent communication requires a different access model from human administration.

The Wazuh manager needs to accept connections from legitimate agents, but the trusted source addresses may span multiple networks.

For example:

Corporate Endpoints
10.10.0.0/16

Server Network
10.20.0.0/16

Cloud Workloads
10.30.0.0/16

If agent networks are dynamic, an IP allowlist may be difficult to maintain.

In those environments, combine network restrictions with strong agent authentication, enrollment controls, segmentation, and appropriate firewall policies rather than relying exclusively on static IP addresses.

Restrict Wazuh Dashboard Access

The Dashboard should not normally be exposed broadly to the Internet.

A stronger architecture is:

Internet
   |
   X
   |
VPN / Zero Trust Access
   |
   v
Trusted SOC Network
   |
   v
Wazuh Dashboard

This reduces the number of systems capable of reaching the user-facing administrative interface.

Where external access is necessary, use a controlled reverse proxy or secure remote-access architecture rather than exposing the Dashboard directly whenever practical.

Restrict Wazuh API Access

The Wazuh API is particularly sensitive because it exposes management functionality programmatically.

Access should therefore be limited to systems that genuinely require it.

For example:

SOC Workstations       → API
Automation Server      → API
Monitoring Platform    → API
Public Internet        → DENY
General User Network   → DENY

Network restrictions should complement API authentication and RBAC.

An allowed IP address does not mean the client should receive unrestricted API privileges.

Restrict Wazuh Indexer Access

The Wazuh Indexer contains security data and should have an especially narrow network boundary.

A common architecture is:

Wazuh Dashboard ─────┐
                     │
Wazuh Server ────────┼──> Wazuh Indexer
                     │
Authorized Admin ────┘

Untrusted Network ───────> DENY

The indexer should generally not be directly accessible from ordinary user networks.

Wazuh’s security guidance recommends restricting access to the indexer API to trusted networks and protecting communications with TLS.

Use CIDR Ranges Safely

CIDR ranges make network allowlisting easier to manage, but overly broad ranges can undermine the purpose of the whitelist.

For example:

192.168.10.25/32

represents a single IPv4 address.

Whereas:

192.168.10.0/24

represents an entire subnet.

Administrators should use the smallest practical CIDR range.

Avoid allowing:

0.0.0.0/0

unless there is an explicitly documented architectural reason and additional controls protect the service.

A broad allowlist can effectively turn an intended network restriction into an Internet-accessible service.

Combine IP Allowlisting With RBAC

IP allowlisting should never replace identity-based authorization.

Instead, the controls should work together:

Source IP
   ↓
Network Allowlist
   ↓
Authentication
   ↓
Role Mapping
   ↓
RBAC
   ↓
Tenant
   ↓
Data Permissions

For example, an attacker might obtain an analyst’s credentials.

If the attacker connects from an untrusted network, the firewall can block the connection before authentication.

If the attacker connects from an approved network, authentication and RBAC still limit what the compromised account can do.

This is classic defense in depth.

Use a Reverse Proxy for External Administration

A reverse proxy can provide a controlled entry point for administrative access.

A common architecture is:

Administrator
     |
     v
VPN / Secure Access
     |
     v
Reverse Proxy
     |
     +---- IP Filtering
     +---- TLS
     +---- Access Logging
     |
     v
Wazuh Dashboard

A reverse proxy can centralize controls such as TLS termination, IP filtering, request logging, and additional authentication mechanisms.

It should not be treated as a replacement for Wazuh authentication and authorization.

The backend Wazuh services should remain protected independently.

Validate Allowed and Blocked Connections

After implementing network restrictions, test from multiple locations.

At minimum, verify:

Trusted source

• Dashboard connection succeeds.
• API connection succeeds when authorized.
• Expected Wazuh functionality works.

Untrusted source

• Dashboard connection is blocked.
• API connection is blocked.
• Indexer connection is blocked.

Also test the failure path deliberately.

A network access policy is not complete until you have verified both:

Expected Source → ALLOW
Unexpected Source → DENY

Record the results as part of the Wazuh security configuration documentation.

Back Up Wazuh Access-Control Configuration

Access-control configuration is security-critical infrastructure.

Losing users, roles, role mappings, tenant configuration, or related authorization settings during a Wazuh failure can significantly delay recovery and potentially leave the organization with incorrect permissions.

A robust backup strategy therefore needs to protect not only Wazuh data but also the configuration that determines who can access that data.

Related Guide: How to Backup Wazuh RBAC Configurations

Why RBAC Backups Are Important

Consider a Wazuh cluster failure in which the organization successfully restores security data but loses its authorization configuration.

The alerts may be available, but:

• Users may not have the correct roles.
• Role mappings may be missing.
• Tenant assignments may be incorrect.
• Restricted users may receive excessive access.
• Administrators may be unable to perform required operations.
• SSO users may authenticate but receive no permissions.

This demonstrates why RBAC should be treated as recoverable security infrastructure rather than disposable configuration.

Identify Access-Control Configuration That Requires Backup

The backup scope should be based on the components that determine access.

Depending on the Wazuh architecture and version, this can include:

• Wazuh users
• Roles
• Role mappings
• RBAC policies
• Indexer security configuration
• Tenant configuration
• Relevant authentication configuration
• SSO configuration
• LDAP configuration
• Security certificates and associated configuration where required
• Supporting configuration files

Do not assume that backing up /var/ossec/etc/ alone creates a complete access-control backup.

Some authorization data is associated with the Wazuh Indexer security configuration and must be backed up using the appropriate indexer/security mechanisms.

Back Up Wazuh Roles and Role Mappings

Roles and role mappings should be captured regularly.

The backup should preserve the relationship between:

Identity
   ↓
Backend Role / Group
   ↓
Role Mapping
   ↓
Wazuh Role
   ↓
Permissions

A role backup without the associated mappings may leave the organization with a collection of permissions but no reliable way to restore who receives them.

Back Up Tenant Configuration

Organizations using multi-tenancy should also include tenant-related security configuration in their recovery plan.

The backup should preserve the relationship between:

• Users
• Groups
• Roles
• Tenants
• Index permissions
• Data-access policies

This is particularly important in multi-customer environments.

Losing tenant mappings can result in either excessive access or complete loss of legitimate visibility.

Protect Backup Files

Access-control backups are themselves sensitive.

A backup containing privileged roles, authentication settings, certificates, or security configuration should be treated as confidential security information.

Protect backups using:

• Strict filesystem permissions
• Dedicated backup accounts
• Encryption
• Access logging
• Backup integrity verification
• Controlled administrative access

Avoid storing privileged configuration backups in publicly accessible locations.

Encrypt Sensitive Backups

Backups should be encrypted both during transmission and while stored.

This is especially important if backups are transferred to:

• Remote backup servers
• Cloud storage
• Object storage
• Off-site facilities
• Disaster-recovery environments

Encryption reduces the impact if backup media or storage credentials are compromised.

Encryption keys should also be protected separately from the backup data wherever practical.

Store Backups Separately From the Wazuh Cluster

A backup stored on the same host as the production Wazuh deployment does not provide strong disaster recovery.

If an attacker compromises the cluster and deletes or encrypts local backups, both the production system and recovery copies could be lost.

A stronger architecture is:

Wazuh Cluster
     |
     | Encrypted Backup
     v
Separate Backup Server
     |
     v
Off-Site / Immutable Storage

The backup environment should have its own access controls and should not be writable by ordinary Wazuh administrator accounts unless necessary.

Automate Backup Schedules

Manual backups are easily forgotten.

Automated backups should run according to the organization’s recovery requirements.

A schedule might include:

• Daily configuration backups
• Weekly retained copies
• Monthly long-term copies
• Backups before major Wazuh upgrades
• Backups before major RBAC changes

The backup process should produce an auditable result indicating whether the backup succeeded or failed.

A backup job that silently fails is worse than one that does not exist because it creates false confidence.

Test Restoration Procedures

A backup is not proven until it has been restored successfully.

Regular restoration tests should verify that the organization can recover:

• Users
• Roles
• Role mappings
• Tenants
• Permissions
• Authentication configuration
• Required security settings

Restoration should ideally be tested in an isolated recovery environment rather than directly against production.

Document every restoration test and record any differences between the restored configuration and the expected configuration.

Validate Permissions After Recovery

After restoring access-control configuration, perform an authorization test.

At minimum, validate:

Administrator

• Can access required administrative functions.

Analyst

• Can access required security data.
• Cannot modify restricted configuration.

Responder

• Can perform approved response operations.

Auditor

• Has read-only access to approved information.

Restricted tenant user

• Can access only the intended tenant.

Unauthorized user

• Cannot access protected resources.

This final validation is critical because a successful configuration restore does not automatically prove that the restored security boundaries are correct.

Troubleshoot Wazuh Access Control

Wazuh access-control problems can originate from many layers.

A user may fail to authenticate, authenticate successfully but receive no data, receive the wrong role, encounter permission errors, or unexpectedly access information belonging to another tenant.

The most effective troubleshooting strategy is therefore to work through the access-control chain systematically rather than changing permissions randomly.

Related Guide: Troubleshooting Wazuh RBAC

Users Cannot Log In

Start by determining whether the problem is authentication or authorization.

If the user cannot authenticate at all, investigate:

• Username or password
• Account status
• Password expiration
• Failed-login protections
• SSO configuration
• LDAP connectivity
• SAML configuration
• OIDC configuration
• Identity-provider availability
• TLS certificates
• Network connectivity

If the authentication provider is external, verify that the identity provider itself is functioning before changing Wazuh permissions.

A user who never successfully authenticates cannot be fixed by changing an RBAC role.

Users Can Log In but Cannot Access Data

This indicates that authentication may be working while authorization or data access is failing.

Check:

1. The user’s effective role.
2. Role mappings.
3. Tenant assignments.
4. Index permissions.
5. Document-level restrictions.
6. Field-level restrictions.
7. Dashboard permissions.

A useful diagnostic distinction is:

Cannot Log In
      ↓
Authentication Problem

Can Log In
      ↓
Cannot Access Data
      ↓
Authorization / Data-Access Problem

This prevents administrators from unnecessarily changing passwords when the actual problem is a missing role or tenant permission.

Permission-Denied Errors

HTTP 403 Forbidden responses generally indicate that the request reached the service but the authenticated identity does not have sufficient authorization.

When troubleshooting, identify:

• Which user made the request.
• Which service received it.
• Which resource was requested.
• Which role was applied.
• Which permission was required.
• Whether tenant restrictions apply.
• Whether document or field security applies.

Do not solve every 403 error by assigning administrator privileges.

That approach hides the underlying policy problem and violates least privilege.

Incorrect Role Mappings

Incorrect role mappings are one of the most common causes of unexpected permissions.

For SSO users, verify:

Identity Provider Group
          ↓
Received Attribute / Backend Role
          ↓
Wazuh Role Mapping
          ↓
Effective Wazuh Role

Check for:

• Misspelled group names
• Incorrect attribute names
• Unexpected capitalization
• Missing backend roles
• Conflicting mappings
• Overly broad wildcard mappings
• Users belonging to multiple groups

The goal is to identify the effective role, not simply the role an administrator expects the user to have.

RBAC Changes Not Taking Effect

If a newly assigned role does not appear to work, check:

• Whether the change was saved successfully.
• Whether the correct user was modified.
• Whether the role mapping is correct.
• Whether the user needs to establish a new session.
• Whether multiple roles are affecting the effective permission set.
• Whether the Dashboard and API are using the same authorization path.
• Whether the underlying security configuration has been successfully applied.

Have the user sign out and establish a new authenticated session after significant authentication or authorization changes.

For persistent problems, compare the effective configuration against a known-good account.

Multi-Tenancy Isolation Problems

If users can see data from the wrong tenant, immediately treat the issue as a security concern.

Review:

• Tenant assignments
• Role mappings
• Backend roles
• Index permissions
• Document-level security
• Dashboard tenant configuration

Test with a low-privilege account rather than an administrator.

If a user cannot access the expected tenant, determine whether the problem is:

Tenant Assignment
       ↓
Role Mapping
       ↓
Index Permission
       ↓
Underlying Data

For detailed multi-tenancy troubleshooting: How to Set Up Wazuh Multi-Tenancy

Field-Level Security Not Working

If restricted fields remain visible, verify:

• The user is actually using the restricted role.
• The correct index is covered by the FLS policy.
• Another role does not provide broader access.
• The field name matches the actual indexed field.
• The Dashboard query is accessing the expected index.
• The test account does not have administrative privileges.

If fields are missing unexpectedly, perform the same checks in reverse.

Field-level security problems can also manifest as broken visualizations or incomplete search results when dashboards depend on fields that have been restricted.

SSO Users Receiving Incorrect Permissions

When SSO users receive unexpected permissions, start at the identity provider.

Determine:

1. Which groups the user belongs to.
2. Which identity claims are being sent.
3. Which backend roles Wazuh receives.
4. Which role mappings match those roles.
5. Which Wazuh roles are ultimately assigned.

For example:

User
 ↓
Microsoft Entra ID / LDAP / IdP
 ↓
Group Membership
 ↓
Identity Claim
 ↓
Backend Role
 ↓
Wazuh Role Mapping
 ↓
Effective Permissions

A mistake anywhere in this chain can produce unexpected access.

This is particularly common after organizational changes when identity-provider group structures are modified.

IP Whitelist Blocking Legitimate Administrators

A network allowlist can create a particularly frustrating failure: the authorization configuration may be correct, but the administrator cannot reach Wazuh at all.

Check:

• Source IP address
• VPN address
• NAT behavior
• Firewall rules
• CIDR ranges
• Reverse-proxy rules
• Host firewall configuration
• Cloud security groups
• Network routing

The administrator’s visible local IP may not be the IP actually seen by the Wazuh server.

For example:

Administrator
     |
     v
VPN
     |
     v
NAT Gateway
     |
     v
Wazuh Server

Wazuh sees:
10.20.15.24

If the allowlist contains only the administrator’s original workstation address, the connection may be blocked.

Maintain an approved emergency-access path so that a network-policy mistake does not permanently lock administrators out.

Related Guide: How to Configure a Wazuh IP Whitelist

Audit Logs Missing Access Events

If expected access-control events are missing, verify:

• Audit logging is enabled.
• The correct component is generating the event.
• The relevant log source is being collected.
• The event is not being filtered.
• The Wazuh ruleset is processing the event.
• The event is being indexed successfully.
• Retention policies have not removed the event.

Also verify the difference between an event being generated and an event being indexed.

An authentication event may exist on the originating system but never reach the Wazuh Indexer because of a collection or ingestion problem.

For deeper audit configuration: How to Configure Wazuh Audit Logs

Password-Policy Changes Not Being Enforced

If users can still set passwords that appear to violate the configured policy, verify:

• The correct password-policy configuration was changed.
• The policy applies to the account type being tested.
• The configuration was successfully applied.
• The user is using local authentication rather than an external identity provider.
• The test account is not exempt from the policy.
• SSO users are being evaluated against the identity provider’s password policy instead.

This last point is particularly important.

If authentication is delegated to an external identity provider, changing a Wazuh local password policy may not affect the external credentials used by SSO users.

Use a Layered Troubleshooting Method

The fastest way to troubleshoot Wazuh access-control problems is to work from the outside inward:

1. Network
      ↓
2. TLS / Connectivity
      ↓
3. Authentication
      ↓
4. Identity / Backend Roles
      ↓
5. Role Mapping
      ↓
6. RBAC Permissions
      ↓
7. Tenant Access
      ↓
8. Document-Level Security
      ↓
9. Field-Level Security
      ↓
10. Application / Dashboard
      ↓
11. Audit Evidence

This sequence prevents troubleshooting from jumping directly to RBAC when the actual problem may be a firewall, identity provider, certificate, tenant, or index-permission issue.

A disciplined troubleshooting process should also preserve the original configuration before making changes.

Take a configuration backup, document the change, make one controlled modification at a time, and retest the affected account.

That approach makes it much easier to determine which change resolved the problem and reduces the risk of accidentally weakening the Wazuh security model while troubleshooting.

Wazuh Access Control Best Practices

A secure Wazuh access-control architecture is not created by enabling RBAC and leaving it unchanged.

Access control must be continuously reviewed as users, teams, infrastructure, and security requirements change.

The most effective approach combines least privilege, role separation, tenant isolation, data restrictions, network controls, strong authentication, auditing, backups, and regular access reviews.

Follow Least-Privilege Principles

Every Wazuh identity should receive only the permissions required to perform its assigned responsibilities.

Avoid granting administrator privileges simply because they make troubleshooting or daily operations easier.

For example, an analyst who needs to investigate alerts generally does not need permission to:

• Create users
• Modify roles
• Change authentication settings
• Modify index security
• Change tenant configuration
• Administer the Wazuh cluster

Start with the minimum required permissions and expand access only when there is a documented operational requirement.

This follows the principle of least privilege defined by NIST.

Use Dedicated Roles for Different SOC Responsibilities

Create roles around actual responsibilities rather than assigning permissions individually to every user.

A practical SOC could use:

wazuh_admin
wazuh_analyst
wazuh_responder
wazuh_auditor

Each role should have a clearly documented purpose and permission set.

This makes access easier to understand, review, and modify.

It also reduces configuration drift because administrators can update a role once rather than changing dozens of individual accounts.

Separate Administrators From Analysts

Administrators and analysts have fundamentally different responsibilities.

Administrators maintain the Wazuh platform.

Analysts investigate security events.

Combining these responsibilities creates unnecessary privilege.

An analyst account that is compromised should not automatically provide an attacker with the ability to modify Wazuh security configuration.

Use separate administrative roles and, where practical, separate administrative accounts.

Related Guide: How to Configure Wazuh RBAC

Separate Responders From Auditors

Incident responders need operational capabilities that auditors generally do not require.

For example, responders may need additional permissions to investigate and contain incidents, while auditors typically require read-only access.

Giving auditors response capabilities creates unnecessary risk.

Likewise, giving responders unrestricted administrative privileges can expand the blast radius of a compromised responder account.

Design each role around its operational purpose.

Minimize Use of Administrator Privileges

Administrator privileges should be treated as highly sensitive.

Organizations should:

• Limit the number of administrators.
• Avoid shared administrator accounts.
• Use dedicated administrator identities.
• Monitor privileged authentication.
• Review administrator membership regularly.
• Remove unnecessary privileges.
• Protect emergency-access accounts.
• Require stronger authentication for privileged users.

The administrator role should be used when administrative work actually needs to be performed, rather than as the default role for normal Wazuh activity.

Use Multi-Tenancy for Organizational Isolation

Multi-tenancy can isolate security data between teams, business units, environments, or customers.

For example:

Production SOC
     ↓
Production Tenant

Development SOC
     ↓
Development Tenant

Compliance
     ↓
Compliance Tenant

This provides an additional boundary beyond RBAC.

Related Guide: How to Set Up Wazuh Multi-Tenancy

Restrict Sensitive Fields

Not every authorized user needs access to every field in a security event.

Use field-level security where sensitive information must be restricted while preserving access to the underlying security data.

For example, an analyst may need the event timestamp, agent, rule, and source information while another field contains information intended only for a specific security or compliance team.

Field-level restrictions should be based on data classification and operational requirements.

Related Guide: How to Configure Wazuh Field Level Security

Enforce Strong Password Policies

Local Wazuh accounts should have appropriate password controls.

Depending on the deployment and identity architecture, consider:

• Sufficient password length
• Password complexity
• Password history
• Failed-login protections
• Appropriate expiration policies
• Stronger controls for privileged accounts

Where enterprise SSO is available, integrate Wazuh with the organization’s centralized identity provider so authentication policies can be managed consistently.

Related Guide: How to Configure Wazuh Password Policy

Restrict Administrative Interfaces by Network

Do not rely solely on usernames and passwords to protect administrative interfaces.

Restrict access to:

• Wazuh Dashboard
• Wazuh API
• Wazuh Indexer
• Administrative endpoints

using firewalls, security groups, VPNs, reverse proxies, or other network controls.

For example:

Internet
   |
   X
   |
VPN
   |
   v
SOC Network
   |
   +---- Dashboard
   +---- API

Network restrictions provide another barrier if credentials are compromised.

Related Guide: How to Configure a Wazuh IP Whitelist

Enable Comprehensive Audit Logging

Access-control decisions should be observable.

Monitor:

• Successful authentication
• Failed authentication
• Authorization failures
• Administrator activity
• User creation and deletion
• Role changes
• Role mappings
• Tenant changes
• Security configuration changes

Audit logging should allow the organization to reconstruct important access-control events during an investigation.

Related Guide: How to Configure Wazuh Audit Logs

Review Permissions Regularly

Access reviews should be performed on a defined schedule.

During each review, verify:

• User accounts
• Administrator accounts
• Role assignments
• Backend roles
• Role mappings
• Tenant memberships
• Field-level restrictions
• API identities
• Service accounts

The review should answer a simple question:

Does every user still need the access they currently have?

A permission that was appropriate six months ago may no longer be justified after a role change.

Remove Inactive Users and Obsolete Roles

Inactive accounts create unnecessary attack surface.

Remove or disable accounts when users:

• Leave the organization
• Change responsibilities
• No longer require Wazuh access
• Stop working with a particular tenant

Also remove roles that are no longer used.

Unused roles create configuration complexity and can make audits more difficult.

Back Up Access-Control Configurations

RBAC, role mappings, tenant configuration, and related security settings should be included in the organization’s backup strategy.

Backups should be:

• Automated
• Encrypted
• Access-controlled
• Stored separately from production
• Regularly tested

Related Guide: How to Backup Wazuh RBAC Configurations

A backup that has never been restored should not be considered a proven recovery mechanism.

Test Disaster-Recovery Procedures

Access-control recovery should be included in Wazuh disaster-recovery exercises.

Simulate scenarios such as:

• Wazuh Indexer failure
• Loss of security configuration
• Corrupted RBAC data
• Authentication-provider outage
• Accidental role deletion
• Incorrect tenant configuration

After recovery, validate the effective permissions for each major role.

Document Access-Control Changes

Every significant access-control change should have an audit trail.

Document:

• What changed
• Why it changed
• Who approved it
• Who implemented it
• When it was implemented
• Which users or roles were affected
• How the change was tested
• How it can be reversed

This makes troubleshooting, compliance auditing, and disaster recovery substantially easier.

Real-World Wazuh Access Control Example

Consider an enterprise organization operating a centralized SOC with several hundred endpoints across production and development environments.

The organization uses Wazuh to monitor:

• Linux servers
• Windows endpoints
• Cloud workloads
• Network infrastructure
• Authentication systems
• Vulnerability data
• File-integrity events
• Compliance activity

The SOC has four primary user groups:

1. Security administrators
2. Security analysts
3. Incident responders
4. Auditors

The organization decides that every group needs different access.

Enterprise SOC Access-Control Architecture

The resulting architecture looks like this:

                 Enterprise Identity Provider
                           |
                    Authentication
                           |
                           v
                  ┌─────────────────┐
                  │ Wazuh Dashboard │
                  └────────┬────────┘
                           |
                    Role Mapping
                           |
            ┌──────────────┼──────────────┐
            |              |              |
            v              v              v
       Administrators   Analysts       Responders
            |              |              |
            |              |              |
            └──────────────┼──────────────┘
                           |
                     Tenant Access
                           |
               ┌───────────┴───────────┐
               |                       |
          Production                Development
             Tenant                    Tenant
               |
          Data Restrictions
               |
       Field-Level Security

This layered design prevents one control from becoming a single point of failure.

Separate Security Administrators, Analysts, Incident Responders, and Auditors

The organization creates four primary roles.

Each role receives only the permissions necessary for its responsibilities.

Create Dedicated RBAC Roles

The security administrator role receives broad management permissions.

The analyst role receives security-monitoring permissions.

The responder role receives the analyst permissions plus additional operational capabilities.

The auditor role receives primarily read-only permissions.

The organization documents each permission assignment so that the security team can explain why each role has its current capabilities.

Related Guide: How to Configure Wazuh RBAC

Restrict Analyst Access to Appropriate Security Data

Analysts do not automatically receive unrestricted visibility across every business environment.

For example:

SOC Analyst
     |
     +---- Production Tenant ✓
     |
     +---- Development Tenant ✗
     |
     +---- Customer Data ✗

If different analyst teams require different datasets, tenant assignments provide the additional data-isolation layer.

Give Responders Additional Operational Permissions

Incident responders receive broader permissions than analysts because they need to perform approved response activities.

However, they do not automatically receive full administrator privileges.

This creates a separation:

Analyst
  ↓
Investigate

Responder
  ↓
Investigate + Respond

Administrator
  ↓
Manage Platform

This prevents operational response privileges from becoming unrestricted infrastructure-management privileges.

Give Administrators Full Management Privileges

A small group of security administrators receives the permissions required to maintain the Wazuh environment.

Administrative responsibilities include:

• User management
• Role management
• Authentication configuration
• Agent administration
• Security configuration
• Tenant administration
• Integration management
• Platform maintenance

Administrator membership is tightly controlled and regularly reviewed.

Isolate Teams Using Multi-Tenancy

The organization creates separate tenants for different environments.

For example:

Production SOC
      ↓
Wazuh-Production

Development SOC
      ↓
Wazuh-Development

Compliance
      ↓
Wazuh-Compliance

Users receive access only to the tenants associated with their responsibilities.

Related Guide: How to Set Up Wazuh Multi-Tenancy

Restrict Sensitive Fields With Field-Level Security

Some security information is considered more sensitive than ordinary alert metadata.

The organization therefore applies field-level restrictions to selected users.

For example, an analyst may see:

timestamp           ✓
agent.name          ✓
rule.description    ✓
rule.level          ✓
source.ip            ✓
sensitive_field     ✗

This provides additional protection without preventing the analyst from investigating the event.

Related Guide: How to Configure Wazuh Field Level Security

Enforce Password and Authentication Policies

Local administrative accounts are protected by strong password requirements.

Where possible, normal employees authenticate through the enterprise identity provider.

The organization also applies stronger controls to privileged identities, including MFA through the identity-management infrastructure.

This creates separate controls for:

• Identity verification
• Credential protection
• Authorization
• Data access

Restrict Dashboard and API Access by IP

The organization does not expose the Wazuh Dashboard and API to arbitrary Internet clients.

Instead:

Internet
   |
   X
   |
Enterprise VPN
   |
   v
SOC Network
   |
   +---- Wazuh Dashboard
   |
   +---- Wazuh API

The Wazuh Indexer is even more tightly restricted and accepts connections only from authorized Wazuh components and approved administrative systems.

Related Guide: How to Configure a Wazuh IP Whitelist

Enable Audit Logging

All significant access-control activity is monitored.

The SOC tracks:

• Authentication failures
• Successful privileged logins
• Authorization failures
• Role changes
• Tenant changes
• User creation
• User deletion
• Security configuration changes

The security team can then correlate Wazuh administrative activity with identity-provider and network events.

Schedule RBAC Backups

The organization automatically backs up access-control configuration.

The backup process stores encrypted copies on a separate backup infrastructure rather than on the Wazuh cluster itself.

A simplified process is:

Wazuh RBAC Configuration
          |
          v
Automated Backup
          |
          v
Encryption
          |
          v
Separate Backup Server
          |
          v
Off-Site / Protected Storage

Related Guide: How to Backup Wazuh RBAC Configurations

Test the Complete Access-Control Architecture

The SOC performs an end-to-end validation using test accounts.

The test verifies:

Administrator

• Can administer Wazuh.
• Can manage roles.
• Can manage users.
• Can access authorized tenants.

Analyst

• Can investigate alerts.
• Can access assigned security data.
• Cannot manage users.
• Cannot modify RBAC.

Responder

• Can perform authorized response operations.
• Cannot modify unrestricted platform security configuration.

Auditor

• Can review required security information.
• Cannot modify configuration.
• Cannot change roles.

Network validation

• Trusted management networks can connect.
• Untrusted networks are blocked.

Data validation

• Users can access their assigned tenants.
• Users cannot access unauthorized tenants.
• Restricted fields remain hidden.

Recovery validation

• RBAC backups can be restored.
• Permissions remain correct after restoration.

This final test validates the complete chain:

Network
   ↓
Authentication
   ↓
Role Mapping
   ↓
RBAC
   ↓
Tenant
   ↓
Field-Level Security
   ↓
Audit
   ↓
Recovery

That is a substantially stronger approach than validating each feature independently.

How to Audit and Maintain Wazuh Access Control

Wazuh access control should be treated as a continuously managed security control rather than a one-time configuration task.

Employees change roles, teams are reorganized, new applications are integrated, tenants are added, and Wazuh itself is upgraded.

Without periodic maintenance, permissions tend to accumulate.

The result can be privilege creep: users gradually retain access that they no longer need.

Perform Periodic Access Reviews

Establish a recurring access-review process.

Depending on organizational risk, reviews may occur monthly, quarterly, or on another documented schedule.

Review:

• Active users
• Inactive users
• Administrator accounts
• Analyst accounts
• Responder accounts
• Auditor accounts
• Service accounts
• API identities
• Role mappings
• Tenant memberships

Each account should have a documented business or operational justification.

Review Privileged Accounts

Privileged accounts deserve additional scrutiny.

For every administrator, ask:

• Does this person still require administrative access?
• Is the account assigned to a specific individual?
• Is MFA enabled where applicable?
• Is the account monitored?
• Has it been used recently?
• Does the user need every assigned privilege?

Remove unnecessary administrator access rather than leaving it available “just in case.”

Audit Role Assignments

Review the permissions associated with every major role.

Look for:

• Excessive permissions
• Duplicate roles
• Obsolete roles
• Unexpected role inheritance
• Overlapping role mappings
• Privileges that are no longer required

A role should have a clearly documented purpose.

If nobody can explain why a role contains a particular permission, investigate it.

Review Tenant Memberships

Tenant assignments should be reviewed alongside role assignments.

A user may have an appropriate analyst role but still have access to a tenant they no longer need.

Review:

User
 ↓
Role
 ↓
Tenant
 ↓
Data

Changes in organizational responsibilities should trigger tenant-access reviews.

This is especially important in managed security environments where tenant boundaries represent different customers.

Monitor Failed Authentication Attempts

Repeated failed authentication can indicate:

• Password guessing
• Credential stuffing
• Brute-force activity
• Misconfigured applications
• Expired credentials
• Identity-provider problems

Establish detection thresholds appropriate to the environment.

For privileged accounts, repeated failures should receive greater scrutiny.

Monitor Authorization Failures

Authorization failures can reveal both configuration problems and suspicious activity.

For example, repeated attempts by an analyst account to access administrative APIs could indicate:

• An incorrectly configured application
• A misunderstanding of permissions
• Attempted privilege escalation
• A compromised account

Correlate authorization failures with authentication and endpoint activity when possible.

Detect Privilege Escalation

Privilege escalation should be treated as a high-value security event.

Monitor changes such as:

Analyst
   ↓
Responder
   ↓
Administrator

Unexpected privilege changes should generate an investigation.

This is particularly important for changes originating from unusual locations or outside normal administrative workflows.

Review Access-Control Changes

Maintain an audit trail for:

• New users
• Deleted users
• Role creation
• Role deletion
• Permission changes
• Role mappings
• Tenant changes
• Authentication configuration
• Password-policy changes
• Network restrictions

Access-control changes should ideally follow the organization’s change-management process.

For sensitive environments, consider requiring approval before granting privileged access.

Test Security Controls After Wazuh Upgrades

Wazuh upgrades can change security behavior, configuration syntax, component versions, authentication mechanisms, or Dashboard functionality.

After an upgrade, retest:

• Administrator login
• Analyst login
• Responder access
• Auditor access
• SSO authentication
• Role mappings
• API permissions
• Tenant isolation
• Field-level restrictions
• IP restrictions
• Audit logging

Do not assume that a successful software upgrade means the existing authorization model remains fully functional.

Maintain a predefined access-control regression test so that these checks can be performed consistently after upgrades.

Maintain Access-Control Documentation

Finally, document the entire access-control architecture.

The documentation should describe:

• Authentication methods
• Identity providers
• Local accounts
• Roles
• Permissions
• Role mappings
• Tenants
• Field-level restrictions
• Network restrictions
• Audit configuration
• Password policies
• Backup procedures
• Recovery procedures
• Emergency-access procedures
• Access-review schedules

A useful access-control document should allow another qualified administrator to understand who can access Wazuh, how their identity is authenticated, what they can do, what data they can see, where they can connect from, and how the configuration can be recovered.

Keep the documentation synchronized with the actual environment.

Outdated access-control documentation can be almost as dangerous as undocumented access control because administrators may make security decisions based on assumptions that no longer reflect the production configuration.

A mature Wazuh access-control program therefore follows a continuous lifecycle:

Design
  ↓
Implement
  ↓
Test
  ↓
Monitor
  ↓
Review
  ↓
Backup
  ↓
Recover
  ↓
Retest
  ↓
Improve

This lifecycle turns Wazuh access control from a collection of technical settings into an ongoing security-management process.

Frequently Asked Questions

Question: What Is Wazuh Access Control?

Wazuh access control is the collection of authentication, authorization, RBAC, tenant, field-level, and network controls used to determine who can access Wazuh, what they can do, and which security data they can see.

A complete Wazuh access-control strategy can include local users, SSO, SAML, OIDC, LDAP, RBAC, multi-tenancy, field-level security, IP restrictions, and audit logging.

Question: How Does Wazuh Access Control Work?

Wazuh access control operates through multiple security layers.

A typical request follows a flow similar to:

Client
  ↓
Network Access Control
  ↓
Authentication
  ↓
Identity / Backend Roles
  ↓
Role Mapping
  ↓
RBAC Permissions
  ↓
Tenant Restrictions
  ↓
Document / Field Restrictions
  ↓
Requested Resource

Authentication establishes the user’s identity, while authorization determines whether that identity is permitted to perform the requested action.

Question: Does Wazuh Support Role-Based Access Control?

Yes. Wazuh supports role-based access control through its security architecture.

RBAC allows administrators to assign permissions to roles and then assign users or groups to those roles.

This is preferable to manually managing permissions for every individual user because roles can be designed around responsibilities such as:

• Administrator
• Analyst
• Incident responder
• Auditor

Related Guide: How to Configure Wazuh RBAC

Question: What Is Wazuh RBAC?

Wazuh RBAC is a permissions model that controls what authenticated users can access and which operations they can perform.

Instead of granting permissions individually, administrators create roles containing appropriate permissions and map users or backend identities to those roles.

For example:

SOC Analyst
    ↓
Analyst Role
    ↓
Read / Investigate Permissions

A responder can receive additional permissions without receiving the unrestricted privileges assigned to administrators.

Question: What Is the Difference Between Wazuh RBAC and Multi-Tenancy?

RBAC controls what a user is allowed to do.

Multi-tenancy controls which logical security environment or dataset a user can access.

For example:

RBAC
"What actions can Mike perform?"

Multi-Tenancy
"Which security data can Mike access?"

They work together rather than replacing each other.

A user can have analyst permissions while being restricted to a specific tenant.

INTERNAL LINK: How to Set Up Wazuh Multi-Tenancy

Question: Can Wazuh Restrict Access to Specific Fields?

Yes. Wazuh deployments can use field-level security to restrict access to specific fields within indexed security data.

This is useful when users need access to an alert but should not see certain sensitive fields.

Field-level security can be combined with RBAC and other access-control mechanisms to create more granular authorization policies.

Related Guide: How to Configure Wazuh Field Level Security

Question: Can Wazuh Restrict Access by IP Address?

Yes. Network-level controls can restrict which IP addresses or networks are allowed to connect to Wazuh services.

For example, an organization can restrict:

• Dashboard access to the SOC network
• API access to administrator networks
• Indexer access to authorized Wazuh components
• Agent communication to approved networks

IP allowlisting should complement authentication and RBAC rather than replace them.

Question: How Does Wazuh Control Dashboard Access?

Dashboard access can be protected through multiple layers, including:

• Authentication
• SSO
• RBAC
• Tenant permissions
• Field-level security
• Network restrictions
• TLS
• Reverse proxies

A secure deployment should avoid exposing the Dashboard unnecessarily and should limit administrative access to trusted networks whenever practical.

The Dashboard should therefore be treated as an administrative security interface rather than simply a visualization application.

Question: How Does Wazuh Control API Access?

The Wazuh API uses authentication and authorization controls to determine whether a client can perform a requested operation.

API access should be protected using:

• Strong authentication
• Appropriate API permissions
• Least-privilege roles
• Network restrictions
• TLS
• Audit logging

API credentials should never receive broader privileges than required by the application or automation workflow using them.

Question: Does Wazuh Support SSO for Access Control?

Yes. Wazuh can be integrated with enterprise identity providers to provide centralized authentication.

SSO can simplify account management because users authenticate through the organization’s identity infrastructure rather than maintaining separate credentials for every application.

The identity provider can also provide group or role information that is mapped to Wazuh permissions.

Common enterprise identity architectures include:

• SAML
• OpenID Connect
• LDAP
• Enterprise identity providers

Question: Can Wazuh Integrate With SAML and OIDC?

Yes. Wazuh deployments can integrate with identity providers using SAML and OpenID Connect, depending on the authentication architecture and Wazuh version.

The important security concept is that authentication and authorization remain separate.

For example:

Identity Provider
       ↓
Authenticate User
       ↓
Return Identity / Group Information
       ↓
Wazuh Role Mapping
       ↓
Wazuh Permissions

A successful SSO login does not automatically mean the user should receive administrative permissions.

The identity-provider groups or attributes must be mapped appropriately to Wazuh roles.

Question: How Do I Troubleshoot Wazuh Permission Errors?

Start by determining whether the problem is authentication or authorization.

If the user cannot log in, investigate authentication.

If the user can log in but receives a 403 Forbidden or cannot access expected data, investigate authorization.

Check the following in order:

1. Network connectivity
2. TLS and certificates
3. Authentication
4. User identity
5. Backend roles
6. Role mappings
7. RBAC permissions
8. Tenant membership
9. Document-level restrictions
10. Field-level restrictions
11. Dashboard or API configuration

Avoid immediately assigning administrator privileges to fix permission errors.

That may hide the underlying configuration problem and violate least-privilege principles.

Question: How Do I Audit Wazuh User Activity?

Enable and monitor the appropriate audit and security logs across the Wazuh environment.

Important events include:

• Successful authentication
• Failed authentication
• Authorization failures
• User creation
• User deletion
• Role changes
• Role-mapping changes
• Tenant changes
• Privileged administrative activity
• Security configuration changes

These events can be forwarded into security monitoring workflows so suspicious access-control activity can generate alerts.

Question: How Should I Back Up Wazuh Access-Control Settings?

Back up the security configuration that controls authentication and authorization, including relevant roles, role mappings, tenant configuration, and supporting security configuration.

Backups should be:

• Automated
• Encrypted
• Access-controlled
• Stored separately from production
• Protected against unauthorized modification
• Regularly tested through restoration exercises

Do not consider a backup successful merely because a backup file exists.

Periodically restore the configuration in a test environment and verify that users receive the expected permissions.

Question: What Are the Best Practices for Wazuh Access Control?

The most important Wazuh access-control practices are:

1. Follow least privilege.
2. Use dedicated roles for different SOC responsibilities.
3. Separate administrators from analysts and responders.
4. Use multi-tenancy to isolate security data.
5. Restrict sensitive fields when necessary.
6. Use strong authentication and password policies.
7. Protect Dashboard and API access with network controls.
8. Use SSO where appropriate.
9. Enable comprehensive audit logging.
10. Review users, roles, and permissions regularly.
11. Remove inactive accounts and obsolete roles.
12. Back up access-control configuration.
13. Test disaster recovery.
14. Retest permissions after Wazuh upgrades.
15. Document significant access-control changes.

The key principle is to use multiple complementary controls rather than relying on one mechanism.

A mature Wazuh environment combines:

Authentication
       +
RBAC
       +
Multi-Tenancy
       +
Field-Level Security
       +
Network Restrictions
       +
Audit Logging
       +
Backup / Recovery

This layered approach limits both unauthorized access and the potential impact of compromised accounts.

Conclusion

Wazuh access control is more than creating users and assigning passwords.

A secure Wazuh deployment requires a layered authorization architecture that determines who can authenticate, what they can do, which data they can access, where they can connect from, and how their activity is monitored.

RBAC provides the foundation for separating responsibilities between administrators, analysts, incident responders, and auditors.

Multi-tenancy adds logical isolation between teams and environments, while field-level security provides additional control over sensitive information.

Authentication mechanisms such as local accounts, SAML, OIDC, and LDAP can establish trusted identities, but authentication alone does not determine what those identities are allowed to do.

Proper role mapping and least-privilege authorization remain essential.

Network controls provide another security boundary.

Restricting Dashboard, API, and Indexer access to trusted networks can reduce exposure if credentials are compromised.

Strong password policies and enterprise SSO can further strengthen identity security.

Access control must also be observable and recoverable.

Audit logging provides evidence of authentication, authorization, and administrative activity, while regular backups ensure that critical RBAC and security configuration can be restored after a failure.

The most effective Wazuh access-control architecture therefore follows a defense-in-depth model:

Trusted Network
      ↓
Secure Connection
      ↓
Authentication
      ↓
Identity / Role Mapping
      ↓
RBAC
      ↓
Tenant Isolation
      ↓
Field / Data Restrictions
      ↓
Audit Logging
      ↓
Continuous Review
      ↓
Backup and Recovery

The objective is not simply to prevent unauthorized users from logging into Wazuh.

The objective is to ensure that every authenticated identity has exactly the access required to perform its legitimate responsibilities, and no more.

For enterprise SOC environments, this approach makes Wazuh access control easier to audit, troubleshoot, maintain, and recover while reducing the risk created by excessive privileges and poorly managed security configuration.

By combining RBAC, multi-tenancy, field-level restrictions, strong authentication, IP allowlisting, audit logging, and tested backups, organizations can build a Wazuh security architecture that remains resilient as users, teams, and infrastructure evolve.