Scope Wazuh registry change reports to supported value types

Bottom line: Decide whether the requirement is a change notification or the changed value content. Limit the latter to the documented types and assess what the endpoint will retain before enabling it broadly.

Source fact: documented behavior

The Windows Registry monitoring guide describes periodic registry scans and says newly created matching keys are scanned from the next scheduled FIM scan.

For exact-content reporting, it documents report_changes for REG_SZ, REG_EXPAND_SZ, REG_MULTI_SZ, REG_DWORD, REG_DWORD_BIG_ENDIAN and REG_QWORD values.

The guide warns that this reporting stores monitored copies in the agent’s registry diff directory and increases storage use.

What the source does not establish

This article scopes exact-content registry reporting. It does not extend the supported-type list, promise an immediate alert or approve retaining sensitive value contents merely because monitoring a key is already authorized.

Applicability questions

• Which exact keys and value types are in scope?
• Does the investigation need contents or only evidence of change?
• What scheduled scan applies to those entries?
• Who approves the local diff-copy population and its capacity?

DSE recommendation: controlled next steps

The following steps are DSE recommendations based on the cited source.

DSE recommends a value-type and content-need review before enabling exact registry change reporting on a bounded key population.

1. List the proposed registry keys, their actual value types and the investigation reason for seeing contents. Separate values requiring only a modification signal from those whose before-and-after content is necessary. Have the endpoint and data owners review the latter population explicitly. Do not broaden a registry subtree simply to avoid deciding which information the investigation actually needs.
2. Compare each proposed type with the source’s supported list and the installed configuration reference. Keep an unsupported or unknown type unresolved rather than promising equivalent output. Review the scan interval and the treatment of a key created after the initial scan with the investigator. Distinguish that timing question from whether the reporting option has been accepted by the agent.
3. Prepare a disposable key with harmless values for a controlled trial. Review the local diff storage location and capacity with the endpoint owner, preserving existing monitoring settings before the change. Keep the test key separate from application and startup keys. Restore the agreed configuration and remove only the authorized test objects through their normal change procedure when the trial ends.

Verification and evidence

Proposed verification: record one allowed value type, the initial harmless value and a planned replacement. Observe the actual next applicable scan and compare the resulting change evidence with the stated requirement. Include a separately created matching test key so its scan timing is observed rather than assumed. No registry mutation or FIM scan was performed for this article.

Retain redacted type, timing and alert evidence together with actual endpoint storage observations. Confirm that no unapproved sensitive contents were included in the reviewed population. A demonstrated change for one value type does not validate all registry types, every descendant key or immediate collection; leave those additional cases outside the acceptance record.

Official references

• Windows Registry monitoring — Wazuh; official product documentation.

Source review completed October 30, 2026. Recheck the official source and deployment-specific applicability before changing production settings.