How to Configure Wazuh Field Level Security

Wazuh Field Level Security (FLS) provides a way to restrict which individual fields users can read from documents stored in the Wazuh indexer. Instead of giving every analyst access to an entire Wazuh document, administrators can create roles that expose only the fields required for a user’s job.

This is particularly useful in environments where Wazuh collects security information containing sensitive usernames, IP addresses, endpoint details, command-line arguments, authentication data, vulnerability information, or other operational metadata.

Wazuh is built around a Wazuh server, Wazuh indexer, and Wazuh dashboard.

The Wazuh server analyzes security events and forwards relevant data to the indexer, while the dashboard queries and visualizes that indexed information.

Field-level restrictions are enforced at the OpenSearch Security layer used by the Wazuh indexer.

This means the objective is not simply to hide columns or dashboard elements from the Wazuh Dashboard.

The underlying security controls determine which fields a user can retrieve from the protected index.

For organizations implementing the principle of least privilege, this provides another layer of access control.

NIST defines least privilege as restricting users or processes to the minimum access necessary to perform their assigned tasks.

What Is Wazuh Field Level Security?

Definition of field-level security

Field-level security controls which fields within an indexed document a role can read.

For example, suppose a Wazuh alert contains fields such as:

agent.name
agent.ip
rule.id
rule.description
data.srcip
data.srcuser
data.command
full_log

An administrator could create a role that permits an analyst to see:

agent.name
agent.ip
rule.id
rule.description
data.srcip

while excluding fields such as:

data.srcuser
data.command
full_log

The document itself still exists in the Wazuh indexer, but the restricted user cannot retrieve the excluded fields through operations protected by FLS.

OpenSearch supports both include and exclude approaches.

An include policy specifies the fields a role is allowed to retrieve, while an exclude policy removes specific fields from the result.

Wildcards can also be used when multiple fields share a naming pattern.

This distinction is important when protecting Wazuh data because security events frequently contain considerably more information than an analyst needs to perform a particular task.

How field-level security differs from index- and document-level security

Wazuh access control can be considered at several different levels.

Index-level security determines which indexes a role can access.

For example, an administrator might allow a role to access:

wazuh-alerts-*

while denying access to other Wazuh indexes.

Document-level security (DLS) goes one level deeper.

Instead of restricting an entire index, DLS determines which documents within an index a user can retrieve.

OpenSearch implements DLS through queries that filter the documents returned to a role.

Field-level security (FLS) restricts the fields returned from those documents.

A useful way to visualize the distinction is:

Cluster
   │
   └── Index
        │
        ├── Document 1
        │     ├── Field A
        │     ├── Field B
        │     └── Field C
        │
        └── Document 2
              ├── Field A
              ├── Field B
              └── Field C

Index permissions answer:

Can this role access the index?

DLS answers:

Which documents can this role access?

FLS answers:

Which fields within those documents can this role read?

These controls can be combined to create significantly more granular access policies.

Why granular field access matters in Wazuh

A conventional read-only role can still expose considerably more security information than an employee needs.

For example, a SOC analyst investigating malware may need alert descriptions, rule IDs, timestamps, hostnames, and source IP addresses.

That analyst may not need access to command-line arguments, complete raw event payloads, usernames, or other sensitive fields.

Giving users access to unnecessary information increases the amount of data they can potentially inspect or export.

FLS addresses this problem by applying least-privilege principles at the field level. OpenSearch describes its security model as supporting increasingly granular controls at the cluster, index, document, and field levels.

This is particularly valuable in larger security operations centers where different teams may work with the same underlying Wazuh data but have different access requirements.

Common use cases for protecting sensitive security data

Common Wazuh FLS use cases include:

• SOC analyst access: Allow analysts to investigate alerts without exposing unnecessary sensitive fields.
• Tiered SOC access: Give Tier 1 analysts less data access than Tier 2 or Tier 3 responders.
• Incident response: Expose investigation-specific fields while restricting unrelated endpoint information.
• Managed security services: Prevent one customer or tenant from accessing fields that should remain outside their assigned scope.
• Compliance requirements: Reduce exposure of sensitive information to users who do not require it.
• Security operations reporting: Give reporting users access to aggregated or operational fields without granting unrestricted event visibility.
• Administrator separation: Allow operational administrators to work with Wazuh data without automatically giving them access to every sensitive field.

For example, an organization could allow a junior analyst to view:

agent.name
agent.ip
rule.id
rule.level
rule.description
timestamp

while reserving fields such as:

full_log
data.command
data.srcuser

for incident responders or security administrators.

This How to Set Up Wazuh Multi-Tenancy guide can be used alongside field-level controls when designing more comprehensive separation between Wazuh users and security teams.

How Wazuh Field Level Security Works

Wazuh Field Level Security is implemented through the security capabilities of the Wazuh indexer rather than through the visual presentation layer of the dashboard.

The basic data flow looks like this:

Wazuh Agents
     │
     ▼
Wazuh Server
     │
     │ Filebeat / TLS
     ▼
Wazuh Indexer
     │
     │ OpenSearch Security
     │ ├── Roles
     │ ├── Role mappings
     │ ├── Index permissions
     │ ├── DLS
     │ └── FLS
     ▼
Wazuh Dashboard
     │
     ▼
Authenticated User

Wazuh documents this architecture as agents sending events to the Wazuh server, the server analyzing those events, and Filebeat forwarding the resulting data to the Wazuh indexer.

The dashboard then queries the indexed information for visualization.

Wazuh Dashboard and Wazuh Indexer architecture

The Wazuh Dashboard is the interface users interact with, but the Wazuh indexer is where the indexed security documents reside.

The dashboard sends queries to the indexer.

Consequently, field-level restrictions need to be enforced at the data-access layer rather than relying on a dashboard visualization to hide sensitive information.

This distinction matters because a user may access Wazuh data through more than one interface.

The Wazuh indexer also exposes an API that can be accessed from the dashboard, command-line tools such as cURL, or scripts and applications.

A security policy that only hides a field from a dashboard therefore should not be considered equivalent to field-level security.

With FLS, the underlying OpenSearch Security plugin evaluates the authenticated user’s permissions when processing access to the index.

OpenSearch Security and field-level permissions

OpenSearch Security provides the mechanism that Wazuh uses to control access to indexed information.

A security role can contain index permissions that define:

• Which index patterns the role can access
• Which actions the role can perform
• Which documents the role can retrieve
• Which fields the role can retrieve

OpenSearch documentation describes roles as the mechanism for combining cluster-level permissions, index permissions, document-level security, field-level security, and other access controls.

A simplified FLS policy might conceptually look like:

Role: wazuh_analyst_restricted

Index:
    wazuh-alerts-*

Permissions:
    READ

Fields:
    agent.*
    rule.*
    timestamp
    data.srcip

The exact configuration depends on the Wazuh/OpenSearch Security version and deployment, but the underlying concept remains the same: the role defines the fields that the user can retrieve.

Security roles and role mappings

FLS policies are associated with roles rather than directly with individual users.

A typical access-control chain is:

User
  │
  ▼
Role Mapping
  │
  ▼
Security Role
  │
  ├── Index permissions
  ├── Document permissions
  └── Field permissions

For example:

alice
  │
  └── wazuh_analyst
          │
          └── wazuh-alerts-*
                  │
                  └── FLS policy

The role can then be mapped to individual users or backend roles.

This approach is preferable to creating a unique FLS configuration for every user because role-based access control makes policies easier to manage as an environment grows.

OpenSearch recommends using its Dashboards interface or REST API for ongoing management of users, roles, and role mappings rather than treating the YAML configuration files as the primary mechanism for ongoing changes.

Field-level security versus document-level security

FLS and DLS solve different problems and can also be used together.

Consider an organization with several departments:

wazuh-alerts-*
       │
       ├── Finance alerts
       ├── HR alerts
       ├── Engineering alerts
       └── Security alerts

DLS can restrict a user to the documents associated with a particular department.

FLS can then restrict which fields the user sees within those permitted documents.

For example:

DLS:
    Only Finance documents

FLS:
    agent.name
    agent.ip
    rule.id
    rule.description

The result is a two-dimensional restriction:

Which documents?
        +
Which fields?
        =
Granular data access

There is an important configuration consideration here: OpenSearch notes that DLS queries depend on the fields referenced by those queries.

If FLS removes a field required by the DLS query, the security configuration may not behave as intended.

Therefore, when combining DLS and FLS, administrators should ensure that fields required to evaluate the document-level policy remain available to the security mechanism.

How permissions are evaluated when users access Wazuh data

When a user requests Wazuh data, the security layer evaluates the user’s authentication and assigned roles against the requested resource.

Conceptually:

1. User authenticates
        │
        ▼
2. User's roles are identified
        │
        ▼
3. Index permissions are evaluated
        │
        ▼
4. DLS filters permitted documents
        │
        ▼
5. FLS restricts permitted fields
        │
        ▼
6. Authorized data is returned

The important point is that access is determined by the underlying security permissions, not merely by what the Wazuh Dashboard happens to display.

OpenSearch also recommends testing DLS and FLS configurations carefully, particularly when users are assigned multiple roles.

Its security best-practices documentation specifically recommends verifying these configurations and checking the authenticated user’s security information.

Multiple roles deserve particular attention.

OpenSearch evaluates FLS settings across assigned roles, and its documentation recommends consistently using either include or exclude statements for a given index when combining multiple roles.

Mixing approaches can result in unexpected access behavior.

Prerequisites for Wazuh Field Level Security

Before configuring Wazuh Field Level Security, establish exactly where the security policy will be applied and which data needs to be protected.

FLS configuration is an indexer-side security control, so administrators should understand the Wazuh indexer, the relevant index patterns, and the roles assigned to the users who will receive restricted access.

Supported Wazuh deployment

Start with a functioning Wazuh deployment containing the central Wazuh components required for your environment.

Current Wazuh deployments can use an all-in-one architecture or distribute the Wazuh indexer, Wazuh server, and Wazuh dashboard across separate hosts.

Wazuh also supports single-node and multi-node indexer configurations.

For a production environment, document the architecture before changing security policies:

Wazuh Server(s)
      │
      ▼
Wazuh Indexer Node(s)
      │
      ▼
Wazuh Dashboard Node(s)

This becomes especially important in clustered environments because security changes need to be applied consistently to the appropriate security configuration.

The Complete Wazuh Cluster Architecture Guide is a useful background for understanding how the Wazuh server, indexer, and dashboard components interact in distributed deployments.

Wazuh Indexer requirements

The Wazuh indexer must be operational and accessible to the Wazuh Dashboard.

Wazuh describes the indexer as the component responsible for indexing and storing alerts generated by the Wazuh server.

It can be deployed on a single host or as a multi-node cluster.

Before implementing FLS, verify:

• Wazuh indexer nodes are healthy.
• The Wazuh Dashboard can communicate with the indexer.
• Security authentication is functioning.
• The administrator can access indexer security settings.
• Relevant Wazuh indexes exist.
• Existing roles and role mappings are understood.

If the indexer is already experiencing cluster, mapping, or storage problems, resolve those issues before introducing additional access-control complexity.

The Ultimate Wazuh Indexer Guide provides broader coverage of Wazuh indexer architecture, configuration, and administration.

Administrative access

You need sufficient administrative privileges to create or modify security roles and role mappings.

The exact administrative mechanism depends on the Wazuh and OpenSearch Security configuration.

In general, the account used for configuration must be authorized to manage the relevant security settings.

Do not perform the initial configuration using an ordinary analyst account.

A useful principle is to separate:

Security administration
        │
        ├── Create roles
        ├── Configure FLS
        ├── Map roles
        └── Test permissions

Security analysts
        │
        └── Consume authorized Wazuh data

This separation reduces the risk of accidentally granting an analyst administrative privileges while testing field restrictions.

Understanding Wazuh index patterns

Before creating an FLS policy, identify exactly which Wazuh indexes contain the fields you want to protect.

Wazuh uses multiple index patterns for different categories of data.

Examples include:

wazuh-alerts-*
wazuh-archives-*
wazuh-monitoring-*
wazuh-statistics-*
wazuh-states-vulnerabilities-*

Wazuh documents these index patterns and explains the type of information stored in each.

This matters because an FLS policy is applied within an index permission. Restricting:

wazuh-alerts-*

does not automatically mean the same restriction has been applied to every other Wazuh index.

Before configuring the policy, make a simple inventory:

The actual indexes relevant to your environment may vary with your Wazuh version and enabled features.

Identifying fields that require protection

Do not begin by blindly excluding fields.

First identify what different user groups actually need to perform their responsibilities.

For example:

Tier 1 analyst

agent.name
agent.ip
rule.id
rule.level
rule.description
timestamp

Incident responder

agent.name
agent.ip
rule.*
data.*
full_log
timestamp

Security administrator

Broader access

Then identify fields that could contain sensitive information, such as:

full_log
data.command
data.srcuser
data.dstuser
user.*
process.*

The exact fields depend on the events your Wazuh deployment collects.

This exercise also prevents a common mistake: creating an FLS policy so restrictive that dashboards, searches, visualizations, or DLS policies stop functioning correctly.

Backing up the security configuration

Back up the relevant security configuration before making changes.

This is particularly important when modifying an existing production environment because an incorrect role or role-mapping configuration can unexpectedly change access for multiple users.

Record at minimum:

• Existing security roles
• Existing role mappings
• Index permissions
• DLS policies
• FLS policies
• Relevant index patterns
• Administrative access configuration
• Current Wazuh/OpenSearch versions

For larger deployments, take an appropriate Wazuh indexer snapshot according to your operational backup strategy before making significant changes.

Wazuh documents snapshot management as part of its indexer administration capabilities.

See the How to Backup Wazuh Manager Configuration guide for establishing a broader Wazuh configuration-backup process before making security changes.

A final prerequisite is to test the proposed policy with a dedicated test account before assigning it to a large analyst group.

This makes it easier to determine whether the intended fields are visible, whether sensitive fields are actually restricted, and whether existing Wazuh dashboards continue to work as expected.

Identify Sensitive Wazuh Fields

Before configuring Wazuh Field Level Security, identify the information that should be restricted and determine which users actually require access to it.

The goal should not be to hide as many fields as possible.

Instead, apply the principle of least privilege: users should receive the minimum amount of security data necessary to perform their responsibilities.

This is particularly important in Wazuh because a single alert can contain information about an endpoint, user, process, network connection, authentication attempt, application, and the original event payload.

User and identity information

Wazuh events can contain usernames, account identifiers, email addresses, group information, and other identity-related data.

Depending on the logs being collected, potentially sensitive fields can include:

data.srcuser
data.dstuser
user.name
user.id
user.email

The exact field names depend on the log source and decoder that produced the event.

For example, authentication events could contain information identifying the account responsible for an activity.

A Tier 1 analyst may need to know that an authentication failure occurred without necessarily requiring unrestricted access to every identity-related attribute.

A practical policy could therefore allow:

agent.name
agent.ip
rule.id
rule.description
timestamp

while restricting identity-specific fields to incident responders or security administrators.

See How to Monitor Failed SSH Login Attempts Using Wazuh when determining which authentication-related fields should be exposed to analysts investigating failed logins.

IP addresses and host information

IP addresses and endpoint metadata are common components of Wazuh events.

Examples include:

agent.ip
data.srcip
data.dstip
host.ip

Whether these fields should be restricted depends on the organization’s environment.

An IP address may not always be considered highly sensitive, but internal addresses can reveal network architecture, server locations, workstation assignments, or other infrastructure information.

For example, an organization might permit all SOC analysts to access:

agent.name
agent.ip
data.srcip
data.dstip

while restricting additional infrastructure metadata to administrators.

Host information can also reveal:

• Server names
• Operating systems
• Internal network structure
• Application names
• Cloud resources
• Endpoint locations
• Infrastructure roles

See How to Add Linux Endpoints to Wazuh for context for the endpoint information commonly represented in Wazuh data.

Authentication data

Authentication logs deserve particular attention because they can contain information about users, authentication mechanisms, source systems, and potentially sensitive event details.

Examples include:

user.name
data.srcuser
data.dstuser
data.status
data.method

The most sensitive information may also appear inside full_log or custom decoded fields.

For example, a Wazuh event might contain a structured representation such as:

user.name = administrator
source.ip = 10.10.20.15
authentication.method = ssh
authentication.result = failed

A restricted analyst role could expose the result and source IP while limiting access to additional identity information.

It is important to distinguish between event metadata and authentication secrets.

FLS should not be treated as a substitute for proper secret management, credential protection, encryption, or application-level access controls.

Application and infrastructure logs

Wazuh frequently ingests application, web server, database, firewall, operating system, and infrastructure logs.

These events can contain significantly more information than the fields used to generate the associated alert.

For example:

agent.name
rule.id
rule.description
data.srcip
data.url
data.user
data.request
full_log

A security analyst may need the rule description and source IP to investigate an alert but not the complete raw event.

This makes full_log an important field to evaluate.

The full_log field can contain the original event content and may therefore expose information that isn’t obvious from the structured fields shown in a dashboard.

See How to Monitor Apache Logs with Wazuh for understanding how application logs become Wazuh events and which fields may need additional protection.

Compliance-related information

Compliance requirements can also influence which fields should be exposed.

Depending on the environment, Wazuh may process information associated with:

• Employees
• Customers
• Authentication activity
• System accounts
• Internal infrastructure
• Security investigations
• Vulnerability information
• Audit records

For example, an organization might allow a compliance reporting user to access rule IDs, timestamps, control identifiers, and status information while preventing that user from accessing raw event payloads.

FLS should therefore be considered part of a broader data-governance strategy rather than an isolated Wazuh configuration.

The NIST Privacy Framework provides organizations with a structured approach to identifying and managing privacy risks associated with data processing.

Custom fields containing sensitive data

Custom Wazuh decoders and rules can introduce fields that aren’t present in a default deployment.

For example, an organization could create fields such as:

data.customer_id
data.employee_id
data.department
data.application
data.transaction_id
data.internal_ticket

These custom fields should be included in the sensitive-data review.

This is one reason administrators should inspect actual Wazuh events rather than building FLS policies entirely from generic examples.

You can use Wazuh’s log testing functionality to understand how incoming events are decoded and which fields are produced.

See How to Use Wazuh Logtest for identifying the fields produced by custom decoders and rules before creating FLS policies.

Custom fields should also be reviewed whenever new integrations or decoders are introduced.

Determining which users should access each field

Once sensitive fields have been identified, create an access matrix.

For example:

The exact permissions should be determined by your organization’s security, privacy, and compliance requirements.

The important principle is to define job requirements first and FLS policies second.

Understanding Wazuh Security Roles

Wazuh security roles determine what authenticated users can do with data stored in the Wazuh indexer.

Field-level restrictions are therefore not configured in isolation.

They become part of a security role that defines the resources and operations available to the user.

What Wazuh security roles control

A security role can control access at several levels.

Depending on the configuration, this can include:

• Cluster permissions
• Index permissions
• Document-level security
• Field-level security
• Actions a user can perform
• Access to particular Wazuh indexes

Conceptually:

Security Role
│
├── Cluster permissions
│
├── Index permissions
│   ├── Index patterns
│   └── Actions
│
├── Document-level security
│
└── Field-level security
    ├── Allowed fields
    └── Restricted fields

This makes roles the foundation for implementing granular Wazuh access control.

Built-in roles

A Wazuh installation includes predefined security roles for common administrative and operational functions.

The available roles depend on the Wazuh version and security configuration.

Before creating a custom FLS role, inspect the existing roles to determine whether one already provides an appropriate baseline.

Do not modify a built-in role simply because it appears close to what you need.

A safer approach is generally:

Existing role
     │
     ├── Understand permissions
     │
     ▼
Custom role
     │
     ├── Restrict indexes
     ├── Restrict fields
     └── Assign to specific users

This minimizes the possibility of unintentionally changing permissions for existing users.

Creating custom roles

Custom roles are the preferred approach when your access requirements don’t match the existing roles.

For example, you could create:

wazuh_tier1_restricted

with access to selected Wazuh indexes and a limited set of fields.

A second role could provide broader access:

wazuh_incident_response

The two roles could access the same indexes but expose different fields.

For example:

wazuh_tier1_restricted
    ├── agent.*
    ├── rule.*
    ├── timestamp
    └── data.srcip

wazuh_incident_response
    ├── agent.*
    ├── rule.*
    ├── data.*
    ├── full_log
    └── timestamp

This approach makes the access model easier to reason about than creating user-specific permissions.

Role permissions and index access

FLS operates within index permissions.

Therefore, a role must first have access to the relevant Wazuh index before field restrictions become relevant.

For example:

Index pattern:
wazuh-alerts-*

Action:
read

FLS:
agent.*
rule.*
timestamp
data.srcip

The index pattern determines where the role can operate.

The FLS policy determines which fields the role can retrieve.

If the role has no access to wazuh-alerts-*, adding FLS permissions for fields in that index will not grant access to those fields.

Assigning users to roles

After creating a role, it must be associated with the appropriate users.

The basic relationship is:

User
  │
  ▼
Role
  │
  ▼
Index permissions
  │
  ▼
FLS restrictions

For small deployments, directly assigning a user to a role may be sufficient.

For larger environments, role mappings and backend roles provide a more scalable approach.

Role mappings and backend roles

Role mappings connect authenticated users or backend roles to OpenSearch Security roles.

For example:

Backend role:
soc-tier1

        │
        ▼

Security role:
wazuh_tier1_restricted

        │
        ▼

FLS policy:
limited Wazuh fields

This allows an identity provider or authentication system to determine a user’s group or backend role while the Wazuh indexer determines what that group can access.

This becomes especially useful when integrating Wazuh with centralized authentication.

 See How to Configure Wazuh SSO for when role assignments need to integrate with an external identity provider.

See How to Configure Wazuh LDAP Authentication for environments where directory groups are used to drive Wazuh access.

Configure Wazuh Field Level Security

Once you have identified sensitive fields and designed the required roles, you can create the FLS policy.

The recommended approach is to build the policy around job responsibilities rather than individual users.

For example:

Tier 1 Analysts
    ↓
Restricted FLS Role
    ↓
Limited Wazuh fields

Incident Responders
    ↓
Investigation FLS Role
    ↓
Broader *Wazuh fields

Security Administrators
    ↓
Administrative Role
    ↓
Broad access

Create a Custom Security Role

Begin by creating a dedicated security role for the users who require restricted Wazuh data access.

A descriptive name makes the purpose of the role obvious.

For example:

wazuh_tier1_fls

Avoid generic names such as:

analyst
user1
restricted
role2

A role name should communicate its purpose.

For example:

wazuh_tier1_fls
wazuh_incident_response
wazuh_compliance_readonly

Define the role

Define the role around the minimum permissions required by its users.

A restricted analyst role might conceptually contain:

Role:
wazuh_tier1_fls

Purpose:
Tier 1 SOC analysts

Access:
Read-only Wazuh alert data

FLS:
Limited security fields

Avoid adding cluster-level administrative permissions to an analyst role simply because they make troubleshooting easier.

If an analyst requires additional privileges, create or assign a separate role with a clearly defined purpose.

Specify permitted Wazuh indexes

Next, identify the Wazuh indexes the role should access.

For an alert-analysis role, this might be:

wazuh-alerts-*

If the analyst also needs archived event data, you may need to evaluate:

wazuh-archives-*

Do not automatically grant:

wazuh-*

unless the role genuinely requires access to all matching indexes.

Broad wildcard permissions can unintentionally expose additional Wazuh data as the environment evolves.

The Ultimate Wazuh Indexer Guide provides additional guidance on Wazuh indexes and indexer administration.

Configure field-level restrictions

Within the index permission, configure the FLS policy.

There are two primary strategies.

Include only approved fields:

agent.*
rule.*
timestamp
data.srcip

Or exclude specific sensitive fields:

-data.command
-full_log
-data.srcuser

For highly restricted roles, an explicit allow-list approach is often easier to audit because you can clearly see which fields the role is intended to access.

For broader roles where only a small number of fields need protection, an exclusion policy may be more practical.

The correct choice depends on the number of fields, the sensitivity of the data, and how frequently the Wazuh schema changes.

Apply the role to users or groups

After creating the role and defining its FLS policy, map it to the appropriate users or groups.

For example:

User:
analyst01

Backend role:
soc-tier1

Mapped security role:
wazuh_tier1_fls

The role mapping then determines that analyst01 receives the FLS restrictions associated with wazuh_tier1_fls.

Avoid giving the same user another role that provides unrestricted access to the same indexes.

This is especially important when troubleshooting because an administrator may incorrectly conclude that FLS is not working when the user is actually receiving broader permissions through another assigned role.

Configure Field-Level Restrictions

Include specific fields

An allow-list approach explicitly defines the fields available to the role.

For example:

agent.name
agent.ip
rule.id
rule.level
rule.description
timestamp
data.srcip

This is useful for Tier 1 analysts who only require a predictable subset of the event.

The major advantage is that newly introduced fields aren’t automatically exposed merely because they happen to exist in the same Wazuh index.

For sensitive environments, this can provide a stronger default-deny model.

Exclude sensitive fields

An exclusion policy starts with broader access and removes fields that should not be exposed.

For example:

agent.*
rule.*
timestamp
data.*

could be combined conceptually with exclusions such as:

data.command
data.srcuser
full_log

This approach can be convenient when users need access to most fields but only a few fields are sensitive.

However, exclusion-based policies require ongoing review.

If a new custom decoder introduces a sensitive field, that field may become accessible unless it is explicitly added to the exclusion policy.

Restrict access across multiple indexes

A user may need access to more than one Wazuh index.

For example:

wazuh-alerts-*
wazuh-archives-*

Do not assume that an FLS policy defined for one index automatically applies to another index.

Evaluate each index permission independently.

A useful design might be:

wazuh-alerts-*
    FLS: Restricted alert fields

wazuh-archives-*
    FLS: More restrictive fields

wazuh-monitoring-*
    FLS: Agent-status fields

This allows administrators to tailor access to the type of data contained in each index.

Apply different field policies to different roles

Different user groups should generally receive different roles when their data requirements differ.

For example:

This avoids creating a single oversized role that attempts to satisfy every use case.

A role should answer three questions clearly:

1. Who receives it?
2. Which Wazuh data can they access?
3. Which fields can they see?

Map Users to the Custom Role

After configuring the role, map the appropriate users or groups to it.

Create or identify the appropriate user

For testing, create or identify a dedicated non-administrative account.

For example:

Username:
tier1-test

Intended role:
wazuh_tier1_fls

Testing with a dedicated account makes it easier to determine whether the FLS policy is actually responsible for the resulting permissions.

Do not initially test with an administrator account because administrative privileges can obscure the behavior you are trying to validate.

Configure backend roles

If your authentication system supplies group or backend-role information, use that information to drive the role mapping.

For example:

Identity Provider
        │
        ▼
Group: SOC-Tier1
        │
        ▼
Backend role: soc-tier1
        │
        ▼
Wazuh security role:
wazuh_tier1_fls

This is particularly useful for organizations using LDAP, SAML, or OIDC authentication.

 See How to Configure Wazuh SAML Authentication when mapping identity-provider groups to Wazuh roles through SAML.

See How to Configure Wazuh OIDC when using OIDC-based authentication and backend-role mappings.

Map the user or group to the security role

Map the appropriate user or backend role to your custom security role.

For example:

Backend Role:
soc-tier1

Security Role:
wazuh_tier1_fls

The resulting access model becomes:

SOC-Tier1 user
      │
      ▼
soc-tier1 backend role
      │
      ▼
wazuh_tier1_fls
      │
      ├── wazuh-alerts-*
      │
      └── FLS restrictions

For larger organizations, group-based mappings are generally easier to maintain than manually assigning the security role to every user.

Verify effective permissions

Do not consider the configuration complete until you have tested the effective permissions.

Log in as the restricted user and verify that:

• The permitted Wazuh indexes are accessible.
• Expected fields appear in search results.
• Restricted fields are absent.
• Wazuh dashboards continue to function where applicable.
• Searches don’t expose excluded fields.
• Direct index queries cannot retrieve restricted information.
• The user doesn’t receive unrestricted access through another role.

OpenSearch provides security APIs that can help administrators inspect the authenticated user’s security information and troubleshoot role assignments.

A useful validation model is:

                    Expected       Actual
agent.name             ✓              ✓
agent.ip               ✓              ✓
rule.id                ✓              ✓
rule.description       ✓              ✓
data.srcip             ✓              ✓
data.srcuser           ✗              ✗
data.command           ✗              ✗
full_log               ✗              ✗

If a restricted field is visible when it should not be, inspect the user’s complete role assignments and mappings before changing the FLS policy.

A second role with broader permissions can produce results that appear to contradict the FLS configuration.

This verification step is essential because field-level security is only as effective as the complete set of permissions assigned to the user.

Configure Field Level Security Using Wazuh Indexer Security APIs

The Wazuh indexer exposes security-management APIs that can be used to manage roles, role mappings, and other access-control settings.

Using the API is particularly useful when you need to automate Wazuh security configuration, reproduce the same policy across multiple environments, or manage roles without relying exclusively on the graphical interface.

The exact API endpoints and request formats can vary between Wazuh releases because Wazuh’s indexer security layer is based on OpenSearch Security.

Always verify the API behavior against the OpenSearch Security version included with your Wazuh deployment.

Accessing the security API

Security API requests should be sent to a Wazuh indexer node using an account with sufficient security-administration privileges.

A typical request structure looks like:

curl -k -u "admin:YOUR_PASSWORD" \
  -X GET \
  "https://WAZUH_INDEXER:9200/_plugins/_security/api/"

Replace:

WAZUH_INDEXER

with the hostname or IP address of the Wazuh indexer.

The -k option is commonly used in examples where the indexer certificate isn’t trusted by the local system.

In production, however, it is preferable to validate the certificate rather than disabling TLS certificate verification.

For example:

curl --cacert /path/to/root-ca.pem \
  -u "admin:YOUR_PASSWORD" \
  -X GET \
  "https://WAZUH_INDEXER:9200/_plugins/_security/api/"

Use an administrative service account or other appropriately privileged identity rather than embedding credentials into scripts that could be exposed.

Retrieving existing roles

Before creating a custom role, retrieve the existing security roles.

A request can be made against the roles endpoint:

curl -k -u "admin:YOUR_PASSWORD" \
  -X GET \
  "https://WAZUH_INDEXER:9200/_plugins/_security/api/roles"

To retrieve a specific role:

curl -k -u "admin:YOUR_PASSWORD" \
  -X GET \
  "https://WAZUH_INDEXER:9200/_plugins/_security/api/roles/wazuh_tier1_fls"

Review existing roles before creating a new one.

Pay particular attention to:

• Cluster permissions
• Index patterns
• Index actions
• DLS configuration
• FLS configuration
• Existing role mappings

This prevents accidentally duplicating an existing role or overlooking permissions inherited through another role.

See the How to Configure Wazuh LDAP Authentication when existing Wazuh roles are being combined with directory-based authentication and group mappings.

Creating custom roles

A custom role can be created by sending a JSON definition to the security API.

For example:

curl -k -u "admin:YOUR_PASSWORD" \
  -X PUT \
  "https://WAZUH_INDEXER:9200/_plugins/_security/api/roles/wazuh_tier1_fls" \
  -H "Content-Type: application/json" \
  -d '{
    "cluster_permissions": [],
    "index_permissions": [
      {
        "index_patterns": [
          "wazuh-alerts-*"
        ],
        "allowed_actions": [
          "read"
        ],
        "fls": [
          "agent.name",
          "agent.ip",
          "rule.id",
          "rule.level",
          "rule.description",
          "timestamp",
          "data.srcip"
        ]
      }
    ]
  }'

The important part is the relationship between the index permission and the FLS configuration:

index_patterns
       │
       ▼
wazuh-alerts-*
       │
       ▼
allowed_actions
       │
       ▼
read
       │
       ▼
fls
       │
       ├── agent.name
       ├── agent.ip
       ├── rule.id
       └── ...

Important: The exact permission names accepted by the security API depend on the OpenSearch Security version shipped with your Wazuh release.

Treat the example as a configuration pattern and verify the supported action names and role schema for your installed version before applying it to production.

Updating role definitions

Existing roles can be updated through the same security API.

For example:

curl -k -u "admin:YOUR_PASSWORD" \
  -X PUT \
  "https://WAZUH_INDEXER:9200/_plugins/_security/api/roles/wazuh_tier1_fls" \
  -H "Content-Type: application/json" \
  -d '{
    "cluster_permissions": [],
    "index_permissions": [
      {
        "index_patterns": [
          "wazuh-alerts-*"
        ],
        "allowed_actions": [
          "read"
        ],
        "fls": [
          "agent.name",
          "agent.ip",
          "rule.id",
          "rule.level",
          "rule.description",
          "timestamp",
          "data.srcip",
          "data.dstip"
        ]
      }
    ]
  }'

Here, data.dstip has been added to the permitted field set.

Before updating a production role, export or otherwise record its current definition. A mistake in a role update can affect every user mapped to that role.

After updating it, retrieve the role again:

curl -k -u "admin:YOUR_PASSWORD" \
  -X GET \
  "https://WAZUH_INDEXER:9200/_plugins/_security/api/roles/wazuh_tier1_fls"

Compare the returned definition against the intended policy.

Configuring field permissions

FLS can be designed around either an allow-list or an exclusion strategy.

An allow-list might contain:

agent.*
rule.*
timestamp
data.srcip

The role is intended to expose only those fields.

An exclusion strategy instead identifies fields that should not be returned.

Conceptually:

Allowed:
agent.*
rule.*
data.*
timestamp

Restricted:
full_log
data.command
data.srcuser

Allow-list policies are generally easier to reason about when the objective is to expose a small, well-defined set of fields.

Exclusion policies can be convenient when users legitimately need access to most fields but a few specific fields must remain protected.

When FLS and DLS are used together, be especially careful about fields referenced by DLS queries.

Removing a field required to evaluate a document-level restriction can produce unexpected behavior.

Applying role mappings

Creating the role does not automatically assign it to a user.

You must map a user or backend role to the security role.

For example, a backend role called:

soc-tier1

could be mapped to:

wazuh_tier1_fls

A typical API request is:

curl -k -u "admin:YOUR_PASSWORD" \
  -X PUT \
  "https://WAZUH_INDEXER:9200/_plugins/_security/api/rolesmapping/wazuh_tier1_fls" \
  -H "Content-Type: application/json" \
  -d '{
    "backend_roles": [
      "soc-tier1"
    ],
    "users": []
  }'

This creates the conceptual relationship:

SOC-Tier1 group
       │
       ▼
soc-tier1 backend role
       │
       ▼
wazuh_tier1_fls
       │
       ▼
Restricted Wazuh fields

For a small deployment, you could instead map an individual user:

{
  "backend_roles": [],
  "users": [
    "analyst01"
  ]
}

Group-based mappings are generally easier to maintain as the number of users grows.

See How to Configure Wazuh SSO when backend roles originate from an external identity provider.

Verifying the API response

Never assume a successful HTTP response means that the security policy is correct.

First, retrieve the role:

curl -k -u "admin:YOUR_PASSWORD" \
  -X GET \
  "https://WAZUH_INDEXER:9200/_plugins/_security/api/roles/wazuh_tier1_fls"

Then retrieve the mapping:

curl -k -u "admin:YOUR_PASSWORD" \
  -X GET \
  "https://WAZUH_INDEXER:9200/_plugins/_security/api/rolesmapping/wazuh_tier1_fls"

Finally, authenticate as the restricted user and test an actual Wazuh query.

The validation should confirm both sides:

Expected:
    agent.name       visible
    rule.id          visible
    data.srcip       visible

Expected:
    full_log         hidden
    data.command     hidden
    data.srcuser     hidden

Also check whether the user has other roles that grant broader permissions.

Example: Restrict Sensitive Fields in Wazuh

Consider a Security Operations Center with two primary user groups:

• SOC analysts investigate alerts and perform routine triage.
• Security administrators manage Wazuh and require unrestricted access to security data.

The organization wants analysts to investigate alerts without automatically exposing sensitive event content.

Scenario: SOC with analysts and administrators

The environment contains:

Wazuh Agents
     │
     ▼
Wazuh Server
     │
     ▼
Wazuh Indexer
     │
     ├── wazuh-alerts-*
     └── wazuh-archives-*

The SOC defines two roles:

wazuh_soc_analyst
wazuh_security_admin

The analyst role receives restricted field visibility.

The administrator role retains broad access.

Fields that contain sensitive information

After reviewing the organization’s Wazuh events, the security team identifies:

agent.name
agent.ip
rule.id
rule.level
rule.description
data.srcip
data.dstip
data.srcuser
data.command
full_log

The SOC decides that Tier 1 analysts require the first group of fields but don’t need unrestricted access to:

data.srcuser
data.command
full_log

These fields are therefore protected by the analyst FLS policy.

Analyst role with restricted field visibility

The analyst role is designed around an explicit allow-list:

agent.name
agent.ip
rule.id
rule.level
rule.description
data.srcip
data.dstip
timestamp

This means the role isn’t simply hiding three known fields. It explicitly defines the data required for Tier 1 investigation.

That distinction becomes important as the Wazuh deployment grows and additional fields are introduced.

Administrator role with full visibility

Administrators receive a separate role with broader permissions.

Conceptually:

wazuh_security_admin
        │
        ├── Wazuh alert indexes
        ├── Wazuh archive indexes
        └── Broad field visibility

Keeping the roles separate prevents the analyst role from becoming unnecessarily complicated.

Configure the custom role

The administrator creates the analyst role through the Wazuh indexer security API.

A conceptual request could look like:

curl -k -u "admin:YOUR_PASSWORD" \
  -X PUT \
  "https://WAZUH_INDEXER:9200/_plugins/_security/api/roles/wazuh_soc_analyst" \
  -H "Content-Type: application/json" \
  -d '{
    "cluster_permissions": [],
    "index_permissions": [
      {
        "index_patterns": [
          "wazuh-alerts-*"
        ],
        "allowed_actions": [
          "read"
        ],
        "fls": [
          "agent.name",
          "agent.ip",
          "rule.id",
          "rule.level",
          "rule.description",
          "data.srcip",
          "data.dstip",
          "timestamp"
        ]
      }
    ]
  }'

After creating the role, retrieve it and confirm that the intended fields are present.

Map users to the role

Suppose the organization’s identity provider supplies:

soc-tier1

as the backend role for Tier 1 analysts.

The security administrator maps it to:

wazuh_soc_analyst

The resulting access model is:

Tier 1 Analyst
      │
      ▼
soc-tier1
      │
      ▼
wazuh_soc_analyst
      │
      ▼
wazuh-alerts-*
      │
      ▼
Approved fields only

See How to Integrate Wazuh with Okta when SOC groups are managed through Okta and mapped to Wazuh security roles.

Test the resulting permissions

The administrator should now log in as a Tier 1 analyst and run representative searches.

The analyst should be able to see:

agent.name
agent.ip
rule.id
rule.level
rule.description
data.srcip
data.dstip
timestamp

The following should not be returned:

data.srcuser
data.command
full_log

Then perform the same investigation using the administrator account.

The administrator should be able to access the broader event information according to the administrator’s role.

A useful test matrix is:

If the analyst can still retrieve a restricted field, inspect all roles assigned to the analyst before changing the FLS policy.

This is one of the most important troubleshooting steps because a broader role can override the intended restriction.

Combine Field Level Security With Document Level Security

Field Level Security and Document Level Security address different dimensions of data access.

FLS determines which fields a user can see.

DLS determines which documents a user can access.

Combining them allows organizations to construct substantially more granular Wazuh access policies.

Why field-level and document-level security can be combined

Consider a Wazuh environment monitoring 5,000 endpoints across several departments.

A user assigned to the Finance SOC team might need:

Only Finance endpoint alerts
+
Only selected fields

FLS alone cannot accomplish this because it controls fields, not which documents belong to Finance.

DLS alone cannot accomplish it because it controls documents, not which fields are visible.

Combining them produces:

DLS
↓
Select permitted documents

FLS
↓
Select permitted fields

Restricting both fields and documents

Suppose every Wazuh alert includes an endpoint identifier.

The organization could use DLS to restrict a role to specific hosts:

DLS:
agent.name belongs to assigned hosts

Then FLS could restrict the fields returned from those documents:

FLS:
agent.name
agent.ip
rule.id
rule.description
data.srcip
timestamp

The result is:

User
 │
 ├── DLS → Which alerts?
 │
 │          Assigned hosts only
 │
 └── FLS → Which information?
            Approved fields only

This provides considerably more precise access control than either mechanism independently.

Example: analysts can only access their assigned hosts

Suppose an enterprise has three SOC teams:

Finance SOC
Engineering SOC
Healthcare SOC

Each team is responsible for a separate collection of endpoints.

DLS can restrict the Finance SOC to documents associated with Finance hosts.

For example, conceptually:

Finance analyst

DLS:
agent.name = finance-server-01
OR
agent.name = finance-server-02
OR
agent.name = finance-workstation-*

The analyst then receives only documents matching the DLS query.

FLS can simultaneously restrict the fields:

agent.name
agent.ip
rule.id
rule.description
data.srcip
timestamp

The user therefore cannot simply search another team’s endpoint and retrieve its events, nor can the user retrieve restricted fields from the events they are authorized to see.

Example: hide sensitive fields while restricting indexes

DLS and FLS can also be combined with index-level permissions.

For example:

Index permissions:
    wazuh-alerts-*

DLS:
    Only assigned hosts

FLS:
    agent.*
    rule.*
    timestamp
    data.srcip

The access-control layers then operate conceptually as:

Can access index?
       │
       ▼
wazuh-alerts-*
       │
       ▼
Which documents?
       │
       ▼
Assigned hosts
       │
       ▼
Which fields?
       │
       ▼
Approved fields

This layered model is particularly useful for multi-team SOC environments.

See How to Set Up Wazuh Multi-Tenancy when multiple teams or organizational units need isolated access to Wazuh security data.

Designing layered access controls

A mature Wazuh access-control architecture should treat permissions as multiple independent layers:

                    ┌─────────────────────┐
                    │   Authentication    │
                    └──────────┬──────────┘
                               │
                               ▼
                    ┌─────────────────────┐
                    │   Role Mapping      │
                    └──────────┬──────────┘
                               │
                               ▼
                    ┌─────────────────────┐
                    │ Index Permissions   │
                    └──────────┬──────────┘
                               │
                               ▼
                    ┌─────────────────────┐
                    │ Document Security   │
                    │       (DLS)         │
                    └──────────┬──────────┘
                               │
                               ▼
                    ┌─────────────────────┐
                    │   Field Security    │
                    │       (FLS)         │
                    └──────────┬──────────┘
                               │
                               ▼
                       Authorized Data

Each layer answers a different question:

This layered approach also makes auditing easier.

Instead of creating one enormous permission rule, administrators can determine exactly where access is being granted or restricted.

For example, if an analyst can see an unauthorized host, investigate DLS and role mappings.

If the analyst can see the correct host but an unauthorized field, investigate FLS and the user’s complete role set.

One final consideration is role composition.

OpenSearch evaluates permissions across the roles assigned to a user, so administrators should avoid accidentally combining a restrictive FLS role with another role that provides unrestricted access to the same data.

This is why testing the user’s effective permissions, rather than testing the custom role in isolation, is critical.

Troubleshooting Wazuh RBAC is useful when a Wazuh user’s effective permissions don’t match the expected role configuration.

Configure Field Level Security for Different Wazuh Teams

A single FLS policy rarely works for every team in a large Wazuh deployment.

Different users consume security data for different purposes, so their access should be based on their responsibilities rather than their job title alone.

The most maintainable approach is to create a small number of purpose-built security roles and map users or groups to those roles.

A typical enterprise model could look like:

SOC Tier 1
    │
    └── wazuh_soc_analyst
            │
            └── Limited fields

Incident Response
    │
    └── wazuh_incident_response
            │
            └── Broader fields

SOC Management
    │
    └── wazuh_soc_manager
            │
            └── Reporting and operational fields

Compliance
    │
    └── wazuh_compliance
            │
            └── Audit-related fields

IT Administration
    │
    └── wazuh_it_admin
            │
            └── Endpoint-focused fields

This role-based model also makes access reviews easier because administrators can evaluate a role once rather than reviewing every individual user.

Security analysts

Tier 1 and Tier 2 security analysts generally need enough information to triage alerts, investigate suspicious activity, and determine whether an event should be escalated.

A Tier 1 analyst might receive:

agent.name
agent.ip
rule.id
rule.level
rule.description
data.srcip
data.dstip
timestamp

Sensitive fields such as:

data.command
data.srcuser
full_log

could remain restricted.

A Tier 2 analyst may require broader visibility because they perform more detailed investigations.

This suggests using separate roles rather than continuously expanding the Tier 1 role:

wazuh_soc_tier1
wazuh_soc_tier2

How to Reduce False Positives in Wazuh is useful for Tier 1 analysts who need access to the alert context necessary to determine whether an event represents a legitimate threat.

Incident responders

Incident responders generally require substantially broader visibility than Tier 1 analysts.

During an investigation, responders may need:

• Process information
• Command-line arguments
• User information
• Source and destination addresses
• File activity
• Authentication events
• Original event data
• Endpoint metadata

A response role might therefore expose:

agent.*
rule.*
data.*
process.*
file.*
timestamp
full_log

The exact fields should still be determined by the organization’s requirements.

Incident responders should not automatically receive administrative privileges simply because they require broad data access.

A useful separation is:

Incident response access
        ≠
Indexer administration
        ≠
Wazuh configuration administration

This maintains separation of duties while still providing responders with the information required to investigate incidents.

How to Detect Ransomware Activity Using Wazuh is relevant when responders need detailed endpoint and event information during ransomware investigations.

SOC managers

SOC managers may require access to security metrics, alert information, trends, and operational data without needing unrestricted access to every raw event.

For example, a management role might expose:

rule.id
rule.level
rule.description
agent.name
timestamp
location
data.srcip

while restricting highly detailed fields such as:

data.command
full_log

This is particularly useful when managers primarily consume dashboards and reports rather than performing hands-on forensic analysis.

A manager’s role should therefore be based on the data required for decision-making rather than simply inheriting the broadest analyst role.

Compliance teams

Compliance personnel often need evidence that security controls are operating but may not require access to every underlying security event.

A compliance-focused role might expose:

timestamp
agent.name
rule.id
rule.description
rule.level

along with fields associated with security-control status, audit events, or vulnerability findings.

Sensitive operational information can remain restricted.

How to Configure Wazuh Audit Logs is useful when designing access for compliance teams that need visibility into audit activity.

IT administrators

IT administrators may need endpoint information to troubleshoot systems without requiring unrestricted access to security investigations.

For example, an IT role might expose:

agent.name
agent.ip
agent.os.*
agent.version
rule.id
timestamp

but restrict:

data.srcuser
data.command
full_log

This can provide IT personnel with useful operational visibility while preventing unnecessary exposure to security investigation data.

See the The Ultimate Wazuh Agent Deployment Guide for additional context for the endpoint and agent information that IT administrators may need.

External security teams

Organizations sometimes provide Wazuh access to an external SOC, managed security service provider, consultant, or incident-response company.

This is a particularly strong use case for granular access controls.

An external team might require:

agent.name
agent.ip
rule.*
data.srcip
timestamp

but should not automatically receive unrestricted access to internal identity information or raw event data.

If external teams are responsible for specific customers, business units, or endpoint groups, combine FLS with DLS.

For example:

External SOC
      │
      ├── DLS → Customer A documents
      │
      └── FLS → Approved fields

This provides two independent restrictions:

Which customer’s data can they access?

and:

Which information within that customer’s data can they see?

Least-privilege access models

A mature Wazuh deployment should use least privilege as the default access model.

A simple hierarchy might be:

The objective is not to create the largest possible number of roles.

Too many roles can become difficult to administer.

Instead, identify meaningful access boundaries and create roles around them.

A good role should have:

• A clearly defined purpose
• A clearly defined user group
• A documented index scope
• A documented FLS policy
• A documented owner
• A review process

Test and Verify Wazuh Field Level Security

FLS should never be considered complete immediately after creating the role.

Test the policy from the perspective of the restricted user and verify the effective permissions rather than simply inspecting the role definition.

The validation process should test the Wazuh Dashboard and direct indexer/API access.

Log in as a restricted user

Start by authenticating as a user assigned to the restricted FLS role.

Do not perform the first test using an administrator account.

For example:

Username:
tier1-test

Assigned role:
wazuh_soc_tier1

Record the user’s expected access before testing:

Expected indexes:
wazuh-alerts-*

Expected fields:
agent.*
rule.*
timestamp
data.srcip

Expected restricted fields:
full_log
data.command
data.srcuser

This provides a baseline against which the actual behavior can be compared.

Verify accessible indexes

Confirm that the user can access the intended Wazuh indexes.

For example:

wazuh-alerts-*       → Allowed
wazuh-archives-*     → Denied

If the user can access an unexpected index, inspect the complete role mapping.

The problem may not be the FLS policy itself. Another role could be granting access to the additional index.

This distinction is important:

Index access problem
        ↓
Review index permissions

Field visibility problem
        ↓
Review FLS

Wrong documents
        ↓
Review DLS

Verify visible fields

Run a representative query against the permitted Wazuh data and inspect the returned document.

For example, an authorized result might contain:

{
  "agent": {
    "name": "web-server-01",
    "ip": "10.10.10.25"
  },
  "rule": {
    "id": "5710",
    "level": 7,
    "description": "Multiple authentication failures"
  },
  "data": {
    "srcip": "10.10.20.15"
  }
}

The restricted fields should not be present in the response.

For example:

data.srcuser
data.command
full_log

should not be returned if the FLS policy excludes them.

Confirm restricted fields cannot be queried

Do not only check whether restricted fields are absent from a dashboard.

Attempt to explicitly request them.

For example, a user might attempt to request:

full_log
data.command
data.srcuser

The important result is that the restricted data is not returned.

This distinction matters because hiding a field from a visualization isn’t the same as preventing the underlying data from being retrieved.

OpenSearch’s FLS mechanism is intended to restrict fields at the security layer.

Test Wazuh Dashboard searches

Log in to the Wazuh Dashboard using the restricted account and perform ordinary alert searches.

Test searches that cover:

• Recent alerts
• High-severity alerts
• Specific agents
• Source IP addresses
• Rule IDs
• Time ranges

Confirm that the expected information appears.

Also check that restricted fields don’t become visible when changing search criteria.

Test Discover and visualization access

If your Wazuh deployment provides access to Discover-style searches or OpenSearch visualizations, test those interfaces separately.

Verify that:

• The restricted user can access permitted data.
• Restricted fields don’t appear in results.
• Existing visualizations don’t expose sensitive information.
• Dashboards don’t fail because they depend on fields removed by FLS.

A visualization that depends on a restricted field may behave differently after FLS is enabled.

This is one reason FLS should be tested against actual dashboards rather than only against individual API queries.

How to Fix Missing Statistics in Wazuh Dashboard is useful when dashboard components don’t display expected data after access-control changes.

Test direct API requests

Dashboard testing alone isn’t sufficient.

Test direct requests against the Wazuh indexer using the restricted user’s credentials.

For example:

curl -k -u "tier1-test:PASSWORD" \
  -X GET \
  "https://WAZUH_INDEXER:9200/wazuh-alerts-*/_search"

Then inspect the returned document.

Attempt to request a restricted field explicitly as part of the query.

The goal is to demonstrate that the sensitive field remains unavailable regardless of whether the request originated from the dashboard or directly from the API.

This is one of the strongest tests that the security policy is enforced at the indexer layer.

Validate permissions after role changes

Repeat the tests whenever you:

• Add fields
• Remove fields
• Modify index patterns
• Change role mappings
• Add another role
• Modify DLS policies
• Change authentication groups
• Upgrade Wazuh
• Upgrade the Wazuh indexer

Pay particular attention to users assigned to multiple roles.

For example:

User
 │
 ├── wazuh_soc_tier1
 │       └── Restricted FLS
 │
 └── wazuh_security_read
         └── Broad access

The user may receive broader access than intended even though wazuh_soc_tier1 itself is correctly configured.

Therefore, always test the user’s effective access, not merely the configuration of the custom role.

Troubleshoot Wazuh Field Level Security

FLS problems generally fall into one of four categories:

Restricted field visible
        │
        ├── Wrong role
        ├── Wrong role mapping
        ├── Broad index permission
        └── Incorrect FLS configuration

Work through these areas systematically rather than immediately rewriting the security policy.

Restricted Fields Are Still Visible

If a restricted field is still visible, first determine whether the field is genuinely being returned by the indexer or is simply being displayed elsewhere by the dashboard.

Run a direct API request using the affected user’s credentials.

If the field appears in the API response, the security policy isn’t restricting it as expected.

If the field is absent from the API response but appears somewhere in the dashboard, investigate the dashboard configuration separately.

Check the assigned role

Retrieve the roles assigned to the affected user and compare them with your intended policy.

The key question is:

Does this user have another role that grants broader access?

For example:

analyst01
   │
   ├── wazuh_soc_tier1
   │      └── Restricted FLS
   │
   └── wazuh_readall
          └── Broad access

In this situation, modifying wazuh_soc_tier1 may not solve the problem because the second role is providing broader access.

Check role mappings

Inspect the role mapping associated with the affected security role.

For example:

curl -k -u "admin:YOUR_PASSWORD" \
  -X GET \
  "https://WAZUH_INDEXER:9200/_plugins/_security/api/rolesmapping/wazuh_soc_tier1"

Look for:

• Unexpected users
• Unexpected backend roles
• Old groups
• Incorrect group names
• Duplicate mappings

A common problem in identity-provider integrations is that a user belongs to a backend group that grants an additional Wazuh role.

For example:

User
 │
 ├── soc-tier1
 │       └── Restricted role
 │
 └── security-users
         └── Broad role

The identity provider may therefore be functioning correctly while the resulting Wazuh permissions are broader than expected.

Verify index permissions

Confirm that the role only has access to the intended Wazuh indexes.

For example:

Expected:
wazuh-alerts-*

Unexpected:
wazuh-*

An overly broad index pattern can expose additional data that wasn’t considered when designing the FLS policy.

Also check whether another role grants access to the same index.

The effective permission set is more important than the individual role definition.

Review field-level configuration

Finally, inspect the actual FLS configuration.

Verify:

• Field names are correct.
• Wildcards aren’t broader than intended.
• The FLS policy is attached to the correct index permission.
• The intended role is actually being used.
• The same index isn’t receiving broader access from another role.
• DLS and FLS aren’t configured in a conflicting way.

Pay particular attention to wildcard patterns.

For example:

data.*

is significantly broader than:

data.srcip
data.dstip

Likewise:

agent.*

may expose considerably more information than a policy containing only:

agent.name
agent.ip

If you use an allow-list, review every permitted field.

If you use an exclusion policy, review whether a newly introduced field has accidentally become visible.

When combining DLS and FLS, also verify that fields required by the DLS query haven’t been removed by the FLS policy.

OpenSearch specifically documents interactions between DLS and FLS that administrators need to account for when designing combined policies.

Troubleshooting Wazuh RBAC is useful for investigating cases where the user’s effective permissions differ from the role you intended to assign.

Best Practices for Wazuh Field Level Security

A well-designed Wazuh Field Level Security implementation should reduce unnecessary data exposure without making legitimate security investigations difficult.

FLS works best when it is treated as part of the organization’s broader identity, access-control, and data-governance strategy rather than as a standalone Wazuh feature.

Follow the principle of least privilege

Give each Wazuh user only the information required to perform their assigned responsibilities.

For example, a Tier 1 analyst may need:

agent.name
agent.ip
rule.id
rule.level
rule.description
timestamp
data.srcip

but may not need:

data.command
data.srcuser
full_log

This reduces unnecessary exposure while still providing enough context for alert triage.

Least privilege should apply to indexes, documents, fields, and administrative capabilities, not just to the fields returned by searches.

Restrict only genuinely sensitive fields

Avoid creating an FLS policy that removes fields simply because they aren’t currently being used.

Overly aggressive restrictions can make investigations unnecessarily difficult.

Instead, classify fields according to their sensitivity and operational value:

Low sensitivity
    agent.name
    rule.id
    rule.level

Moderate sensitivity
    agent.ip
    data.srcip
    data.dstip

High sensitivity
    data.srcuser
    data.command
    full_log
    custom identity fields

The actual classification should reflect your organization’s environment.

This approach provides a better balance between security and usability.

Use role-based access control

Build FLS policies around roles rather than individual users whenever possible.

For example:

wazuh_soc_tier1
wazuh_soc_tier2
wazuh_incident_response
wazuh_compliance
wazuh_security_admin

Users are then assigned to roles based on their responsibilities.

This is considerably easier to maintain than creating:

wazuh_user01
wazuh_user02
wazuh_user03
wazuh_user04

with separate field policies for every employee.

Separate analyst and administrator privileges

Do not give analysts administrative access simply because they need broad visibility into security events.

Separate:

Security data access
        ≠
Wazuh administration
        ≠
Indexer administration

An incident responder may require access to full_log and detailed process information while still not needing permission to modify security roles.

This separation reduces the potential impact of compromised analyst credentials.

Combine field- and document-level security where appropriate

Use FLS when the problem is which fields a user can see.

For DLS, use when the problem is which documents a user can access.

Use both when both restrictions are necessary.

For example:

Finance analyst
    │
    ├── DLS
    │     └── Finance endpoints only
    │
    └── FLS
          └── Approved fields only

This is particularly useful for organizations with multiple business units, customers, or SOC teams sharing one Wazuh environment.

Avoid modifying built-in roles unnecessarily

Before changing an existing Wazuh or OpenSearch Security role, determine who currently depends on it.

Modifying a built-in role can have effects beyond the user you are trying to restrict.

A safer model is:

Existing role
     │
     └── Leave unchanged
     
Custom requirement
     │
     └── Create custom role

For example:

wazuh_soc_tier1
wazuh_soc_tier2
wazuh_incident_response

can be maintained independently.

This also makes future troubleshooting easier because the purpose of each custom role is explicit.

Maintain configuration backups

Back up your security configuration before making significant changes.

Maintain records of:

• Security roles
• Role mappings
• Index permissions
• FLS policies
• DLS policies
• Identity-provider group mappings
• Wazuh and indexer versions

For production environments, incorporate security configuration changes into the organization’s change-management process.

A backup gives administrators a recovery point if a new FLS policy accidentally removes access from a critical SOC team.

See How to Backup Wazuh Manager Configuration as part of a broader Wazuh configuration backup strategy.

Audit security role changes

Treat role and FLS changes as security-sensitive administrative activity.

Record:

Who made the change?
What role changed?
Which fields changed?
Which indexes changed?
When did the change occur?
Why was the change made?
Who approved it?

For example:

2026-08-07
Change: wazuh_soc_tier1
Added: data.dstip
Removed: full_log
Reason: Tier 1 investigation requirements
Approved by: SOC Manager

This creates an audit trail that can be useful during internal reviews and compliance assessments.

Review permissions regularly

Access requirements change as employees change roles, teams are reorganized, and new Wazuh integrations are deployed.

Schedule periodic reviews of:

• Users
• Backend roles
• Security roles
• Index patterns
• FLS policies
• DLS policies
• Exceptions
• Temporary permissions

Pay particular attention to users who have accumulated multiple roles.

A user may start with:

wazuh_soc_tier1

and later receive:

wazuh_incident_response

without the original role being removed.

Periodic access reviews can identify these situations.

Test changes before deploying them broadly

Never introduce a new FLS policy to hundreds of users without testing it first.

Use a dedicated test account:

tier1-fls-test

Then verify:

1. Expected indexes are accessible.
2. Expected fields are visible.
3. Restricted fields aren’t returned.
4. Dashboard searches work.
5. Visualizations continue to work.
6. Direct API requests enforce the restriction.
7. Other assigned roles don’t provide unintended access.

Only after successful testing should the role be mapped to the production group.

Performance and Security Considerations

Field-level security introduces another layer of access control between a user’s query and the data returned by the Wazuh indexer.

For most Wazuh deployments, the security benefits outweigh the additional processing involved.

However, large environments should understand how FLS interacts with query performance, dashboards, and distributed indexer deployments.

Field-level filtering overhead

FLS requires the security layer to apply field restrictions when processing authorized requests.

The practical impact depends on factors such as:

• Number of fields
• Number of documents
• Query complexity
• Number of indexes
• Number of shards
• Number of simultaneous users
• Whether DLS is also enabled
• Dashboard query frequency

A small FLS policy containing a handful of fields generally presents a different workload from a highly complex policy spanning numerous indexes and roles.

Avoid unnecessarily complicated security policies when a simpler policy achieves the same access-control objective.

Query performance

The largest performance consideration is often not FLS itself but the overall query being executed.

Broad searches across large Wazuh indexes can be expensive regardless of field-level security.

For example:

wazuh-alerts-*

combined with a large time range and unrestricted search criteria can generate significantly more work than a narrowly scoped query.

Good performance practices include:

• Limit time ranges where practical.
• Avoid unnecessarily broad index patterns.
• Use appropriate filters.
• Avoid retrieving fields that aren’t needed.
• Maintain appropriate index and shard configurations.
• Monitor indexer resource utilization.

How to Design a Wazuh OpenSearch Shard Allocation Strategy is useful when optimizing Wazuh indexer data distribution in larger environments.

Impact on Wazuh Dashboard searches

Wazuh Dashboard visualizations and searches may depend on particular fields.

If an FLS policy removes a field required by a visualization, the visualization may:

• Return incomplete data.
• Display no results.
• Fail to render.
• Produce misleading statistics.

For example, suppose a dashboard visualization expects:

rule.level

but the FLS policy doesn’t allow that field.

The user may see an empty visualization even though the underlying alerts exist.

This is why FLS testing should include the actual dashboards used by each team.

Security versus usability trade-offs

More restrictive access isn’t automatically better.

If an analyst cannot access the information needed to determine whether an alert is malicious, the organization may create an operational blind spot.

For example:

Too restrictive
       ↓
Analyst cannot investigate
       ↓
More escalations
       ↓
Slower incident response

Conversely:

Too permissive
       ↓
Unnecessary sensitive-data exposure
       ↓
Higher security and privacy risk

The objective is to find the appropriate balance:

Minimum necessary data
          +
Sufficient investigation context
          =
Effective least-privilege access

Scaling field-level policies across large deployments

Large Wazuh environments should avoid creating individual FLS policies for every employee.

Instead, use a role hierarchy based on responsibilities:

SOC Tier 1
SOC Tier 2
Incident Response
Threat Hunting
Compliance
IT Operations
Security Administration

Each role should have a documented access profile.

For example:

wazuh_soc_tier1
    → 8 approved fields

wazuh_soc_tier2
    → 20 approved fields

wazuh_incident_response
    → Broad investigation fields

wazuh_security_admin
    → Administrative access

Identity-provider groups can then be mapped to these roles.

This makes onboarding and offboarding significantly easier:

New analyst
    ↓
Add to SOC-Tier1 group
    ↓
Receives wazuh_soc_tier1
    ↓
Receives predefined FLS policy

No individual field configuration is required for the new employee.

Managing permissions across multiple Wazuh Indexer nodes

In a multi-node Wazuh Indexer cluster, security configuration needs to remain consistent across the deployment.

An FLS policy that works correctly on one node should not be treated as sufficient evidence that the entire cluster is correctly configured.

Administrators should verify:

• Security configuration consistency
• Role definitions
• Role mappings
• Index permissions
• Cluster health
• Node availability
• Authentication behavior

See How to Build a Wazuh Indexer Cluster for additional information about multi-node Wazuh Indexer deployments.

Distributed environments also make configuration management more important.

Security policies should be documented and managed through a controlled administrative process rather than being changed manually without recording what was modified.

Real-World Example: Enterprise SOC

Consider a large enterprise with approximately 8,000 endpoints distributed across corporate offices, cloud infrastructure, and production environments.

The organization operates a centralized SOC with several teams:

                    Enterprise Wazuh
                          │
             ┌────────────┼────────────┐
             │            │            │
          Tier 1       Incident      Security
         Analysts      Response      Admins
             │            │            │
          Limited       Broad       Administrative
           FLS           FLS            Access

The organization also has a compliance team that needs security evidence without unrestricted access to operational event data.

Enterprise Wazuh deployment with multiple SOC teams

The environment uses:

Wazuh Agents
     │
     ▼
Wazuh Server Cluster
     │
     ▼
Wazuh Indexer Cluster
     │
     ▼
Wazuh Dashboard

The organization separates its access model into:

• Tier 1 SOC analysts
• Tier 2 analysts
• Incident responders
• SOC managers
• Compliance personnel
• Security administrators

The organization also uses centralized authentication so that employees can be assigned to groups according to their responsibilities.

See The Complete Wazuh Cluster Architecture Guide for understanding the distributed Wazuh architecture used by this type of enterprise SOC.

Sensitive fields requiring protection

The security team reviews its Wazuh event structure and identifies several categories of sensitive information:

data.srcuser
data.dstuser
data.command
full_log
process.command_line
custom.employee_id
custom.customer_id

The SOC determines that Tier 1 analysts don’t need unrestricted access to these fields.

However, incident responders require most of them during active investigations.

Analyst, responder, and administrator roles

The organization creates three primary roles:

wazuh_soc_analyst
wazuh_incident_response
wazuh_security_admin

The analyst role provides:

agent.name
agent.ip
rule.id
rule.level
rule.description
data.srcip
data.dstip
timestamp

The incident-response role provides significantly broader visibility:

agent.*
rule.*
data.*
process.*
file.*
timestamp
full_log

The administrator role receives the permissions required to manage the Wazuh environment and its security configuration.

The organization deliberately avoids giving the analyst role administrative privileges.

Field-level and document-level restrictions

The enterprise operates several business units.

Each SOC team is responsible for a specific group of endpoints.

The organization therefore combines DLS and FLS.

For example:

Finance SOC analyst
        │
        ├── DLS
        │     └── Finance endpoint documents
        │
        └── FLS
              └── Approved analyst fields

A Finance analyst can therefore see:

Finance Server 01
Finance Server 02
Finance Workstation 15

but cannot retrieve events belonging to Engineering endpoints.

At the same time, even authorized Finance documents expose only the fields permitted by the analyst’s role.

This creates two separate protections:

DLS → Restricts which documents
FLS → Restricts which fields

Role mapping strategy

Rather than mapping every employee individually, the organization uses identity-provider groups.

For example:

SOC-Tier1
SOC-Tier2
Incident-Response
SOC-Management
Compliance
Security-Administrators

These groups are mapped to Wazuh security roles:

SOC-Tier1
    ↓
wazuh_soc_analyst

SOC-Tier2
    ↓
wazuh_soc_tier2

Incident-Response
    ↓
wazuh_incident_response

Security-Administrators
    ↓
wazuh_security_admin

This allows the organization to manage membership centrally.

See How to Integrate Wazuh with Azure AD when enterprise groups are managed through Microsoft identity infrastructure.

See How to Integrate Wazuh with Google Workspace when Google Workspace groups and identities are used to support centralized Wazuh authentication.

Testing and validating access

Before deploying the policies to production users, the SOC creates test accounts for each role:

test-tier1
test-tier2
test-ir
test-admin

Each account is tested against the same scenarios.

Tier 1:

Can access alerts?             Yes
Can view rule information?     Yes
Can view source IP?            Yes
Can view command data?         No
Can view full_log?             No
Can access other team's data?  No

For incident response:

Can access alerts?             Yes
Can view rule information?     Yes
Can view command data?         Yes
Can view full_log?             Yes
Can access assigned hosts?     Yes

For administrators:

Can administer Wazuh?          Yes
Can access required indexes?   Yes
Can access required fields?    Yes

The SOC also performs direct API tests rather than relying exclusively on dashboard testing.

Ongoing permission reviews

After deployment, the organization schedules quarterly access reviews.

The review process examines:

• User membership
• Backend roles
• Security role assignments
• FLS policies
• DLS policies
• Index permissions
• Temporary exceptions
• Newly introduced Wazuh fields

When a new Wazuh integration is deployed, the security team reviews the fields it introduces.

For example, adding a new application log source might create:

data.employee_id
data.customer_id
data.transaction_id

The team evaluates these fields before making the new data broadly available.

The SOC also reviews role changes after employee transfers.

For example:

Tier 1 Analyst
      │
      │ promotion
      ▼
Tier 2 Analyst

The user’s old role is removed and the new role is assigned.

This prevents users from accumulating permissions over time.

The resulting enterprise access model is:

                    Wazuh Data
                        │
             ┌──────────┴──────────┐
             │                     │
        Index Access           Authentication
             │                     │
             ▼                     ▼
            DLS                Role Mapping
             │                     │
             └──────────┬──────────┘
                        │
                        ▼
                       FLS
                        │
                        ▼
                Authorized Fields

This layered approach gives the enterprise a practical way to apply least privilege while preserving the visibility that security teams need to investigate threats effectively.

Frequently Asked Questions

Question: What is Wazuh Field Level Security?

Wazuh Field Level Security (FLS) is an access-control mechanism that restricts which individual fields a user can retrieve from Wazuh data stored in the Wazuh indexer.

For example, an analyst could be allowed to see:

agent.name
agent.ip
rule.id
rule.description
data.srcip

while being prevented from accessing:

data.command
data.srcuser
full_log

The objective is to provide users with the minimum security information necessary to perform their responsibilities.

FLS operates at the indexer security layer, rather than simply hiding information from the Wazuh Dashboard interface.

Question: Does Wazuh support field-level security?

Yes. Wazuh deployments use the Wazuh indexer, which incorporates OpenSearch-based security capabilities that support field-level security.

FLS is configured through the security roles and index permissions applied to users accessing Wazuh index data.

The exact configuration and API syntax depend on the Wazuh and Wazuh indexer versions being used, so administrators should verify the applicable documentation before implementing the policy in production.

Question: What is the difference between field-level and document-level security in Wazuh?

The two controls restrict different aspects of data access.

Field Level Security (FLS) determines which fields within an authorized document a user can see.

Document Level Security (DLS) determines which documents a user can access.

For example:

DLS:
Only Finance endpoint alerts

FLS:
agent.name
agent.ip
rule.id
rule.description

The analyst would receive only Finance alerts and would see only the permitted fields within those alerts.

Index permissions provide another layer:

Index permissions
        ↓
Which indexes?

DLS
        ↓
Which documents?

FLS
        ↓
Which fields?

Question: Can I hide specific Wazuh fields from analysts?

Yes.

You can configure an FLS policy that either explicitly allows specific fields or excludes sensitive fields, depending on the security model you need.

For example, an analyst role could expose:

agent.*
rule.*
timestamp
data.srcip

while restricting:

data.command
data.srcuser
full_log

For highly sensitive environments, an explicit allow-list can make the policy easier to audit because newly introduced fields aren’t automatically exposed.

Question: Can field-level security be applied to Wazuh alerts?

Yes. Wazuh alert data is stored in Wazuh indexer indexes, and FLS can be incorporated into the index permissions governing access to those indexes.

A typical policy might target:

wazuh-alerts-*

and expose only the fields required by a particular analyst group.

For example:

agent.name
agent.ip
rule.id
rule.level
rule.description
timestamp

The policy should be tested against actual alert documents because Wazuh fields vary depending on the event source, decoder, rule, integration, and custom configuration.

Question: Can I combine Wazuh field-level and document-level security?

Yes.

Combining FLS and DLS is one of the most useful approaches for granular Wazuh access control.

For example:

Finance Analyst
       │
       ├── DLS
       │     └── Finance endpoints only
       │
       └── FLS
             └── Approved security fields

DLS controls which events the analyst can access, while FLS controls which fields are visible in those events.

This can be especially valuable for:

• Multi-team SOCs
• Managed security providers
• Multi-tenant environments
• Large enterprises
• Business-unit separation
• External incident-response teams

Question: How do I create a custom Wazuh security role?

A custom security role can be created through the Wazuh indexer’s OpenSearch Security interface or security APIs.

A typical design includes:

Role name
    ↓
Index patterns
    ↓
Allowed actions
    ↓
DLS policy
    ↓
FLS policy
    ↓
Role mapping

For example:

wazuh_soc_tier1

could provide read access to:

wazuh-alerts-*

while restricting the returned fields.

The role should then be mapped to the appropriate users or backend groups.

Question: How do I troubleshoot Wazuh field-level permission errors?

Start by determining whether the problem involves indexes, documents, fields, or role assignments.

Use this sequence:

1. Check user's roles
       ↓
2. Check role mappings
       ↓
3. Check index permissions
       ↓
4. Check DLS
       ↓
5. Check FLS
       ↓
6. Test direct API access

If a restricted field is still visible, check whether another role is granting broader access.

For example:

analyst01
   │
   ├── wazuh_soc_tier1
   │      └── Restricted FLS
   │
   └── wazuh_readonly
          └── Broad access

In this situation, the FLS configuration might be correct while the second role is responsible for the unexpected visibility.

Also verify wildcard patterns such as:

data.*
agent.*

because they can expose significantly more information than intended.

Question: Does field-level security affect Wazuh Dashboard performance?

FLS introduces additional security processing, but its practical performance impact depends on the deployment and query workload.

Factors include:

• Number of fields
• Number of indexes
• Query complexity
• Number of concurrent users
• Number of shards
• Whether DLS is also enabled
• Wazuh Indexer hardware
• Dashboard query frequency

For most deployments, the security benefits of appropriately designed FLS policies outweigh the additional overhead.

However, administrators should monitor indexer performance after implementing complex policies, particularly in large environments.

FLS can also affect dashboard functionality if a visualization depends on a field that the user’s role is not allowed to retrieve.

Question: How often should Wazuh security roles be reviewed?

Review Wazuh security roles regularly and whenever there is a significant change to the environment.

A quarterly access review is a reasonable starting point for many enterprise deployments, although organizations with strict compliance requirements or rapidly changing teams may need more frequent reviews.

Review:

• User memberships
• Backend roles
• Security roles
• Index permissions
• FLS policies
• DLS policies
• Temporary permissions
• Exceptions
• Newly introduced Wazuh fields

Also perform an access review after:

• Employee role changes
• Team reorganizations
• New Wazuh integrations
• Identity-provider changes
• Wazuh upgrades
• Indexer upgrades
• Major security-policy changes

The objective is to prevent permissions from accumulating over time.

Conclusion

Wazuh Field Level Security provides an important layer of granular access control for organizations that need to share security data without exposing every field to every user.

Instead of treating Wazuh access as simply:

Access
or
No Access

FLS allows administrators to establish a more precise model:

Who?
 ↓
Role

Which indexes?
 ↓
Index permissions

Which documents?
 ↓
DLS

Which fields?
 ↓
FLS

Recap of Wazuh Field Level Security

The core process is:

1. Identify sensitive Wazuh fields.
2. Determine which teams actually require those fields.
3. Create purpose-built security roles.
4. Restrict access to the necessary Wazuh indexes.
5. Apply field-level restrictions.
6. Use DLS when document-level isolation is also required.
7. Map users or identity-provider groups to the appropriate roles.
8. Test effective permissions through both the Wazuh Dashboard and direct API requests.
9. Monitor and review the configuration over time.

The most important consideration is to design permissions around actual operational requirements rather than simply creating the most restrictive policy possible.

Importance of granular access control

Wazuh can collect extremely detailed security information from endpoints, applications, authentication systems, network devices, cloud platforms, and other infrastructure.

That visibility is valuable for security operations, but it also means that unrestricted access can expose information that some users don’t need.

Field-level security helps organizations apply least privilege without eliminating the visibility required for security investigations.

For example:

Tier 1 Analyst
    → Alert metadata

Tier 2 Analyst
    → Alert + investigation context

Incident Responder
    → Detailed event information

Administrator
    → Administrative + broad data access

Each role receives the information required for its function.

Combining field, document, index, and role-based permissions

The strongest Wazuh access-control architectures don’t rely on FLS alone.

Instead, combine multiple controls:

Role-Based Access Control
          │
          ▼
    Index Permissions
          │
          ▼
 Document-Level Security
          │
          ▼
  Field-Level Security

Each layer solves a different problem.

Index permissions restrict where users can access data.

DLS restricts which documents they can access.

FLS restricts which fields they can see.

Role mappings determine which users receive those permissions.

Together, these controls can provide highly granular access to Wazuh security data.

Final recommendations for maintaining least-privilege access

For production Wazuh environments, follow these principles:

• Create roles around well-defined responsibilities.
• Give users only the indexes they actually need.
• Use explicit FLS allow-lists for highly sensitive environments.
• Combine FLS with DLS when users should access only specific documents.
• Avoid modifying built-in roles unless there is a compelling reason.
• Keep analyst and administrative privileges separate.
• Use centralized identity-provider groups where possible.
• Test permissions with dedicated accounts before deployment.
• Test direct API access rather than relying only on Dashboard behavior.
• Review users and roles periodically.
• Document security-policy changes.
• Back up security configuration before significant changes.
• Re-evaluate FLS policies whenever new Wazuh integrations or custom fields are introduced.
• Monitor Wazuh Indexer performance after implementing complex access policies.

Ultimately, the goal of Wazuh Field Level Security is not simply to hide information.

It is to create a controlled security-data environment where every user receives enough visibility to perform their job while minimizing unnecessary exposure of sensitive information.

When field-level permissions are combined with role-based access control, index permissions, and document-level security, Wazuh can support a much more granular least-privilege model suitable for enterprise SOCs, compliance teams, managed security providers, and organizations with multiple security teams.