{ "api_version": "1", "kind": "dse_post", "self": "https://update.dsesecurity.com/api/v1/posts/scope-wazuh-registry-change-reports-to-supported-value-types/", "item": { "id": "https://update.dsesecurity.com/updates/scope-wazuh-registry-change-reports-to-supported-value-types/", "slug": "scope-wazuh-registry-change-reports-to-supported-value-types", "url": "https://update.dsesecurity.com/updates/scope-wazuh-registry-change-reports-to-supported-value-types/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/scope-wazuh-registry-change-reports-to-supported-value-types.md", "json": "https://update.dsesecurity.com/api/v1/posts/scope-wazuh-registry-change-reports-to-supported-value-types/" }, "title": "Scope Wazuh registry change reports to supported value types", "summary": "Distinguish registry change detection from exact-content reports. Review the documented supported value types, scheduled-scan boundary and local diff-copy storage before enabling Wazuh report_changes.", "format": { "slug": "guide", "name": "Guide" }, "priority": { "slug": "advisory", "name": "Advisory" }, "featured": false, "image": { "theme": "cyber-defense", "label": "Cyber defense", "alt": "Layered glass and metal cyber-defense structure with controlled blue and gold signal paths.", "card_url": "https://update.dsesecurity.com/assets/editorial/cyber-defense-card.webp?v=1.8.20", "hero_url": "https://update.dsesecurity.com/assets/editorial/cyber-defense-hero.webp?v=1.8.20", "social_url": "https://update.dsesecurity.com/assets/editorial/cyber-defense-social-v2.jpg?v=1.8.20", "width": 2400, "height": 1350 }, "topics": [ { "slug": "cybersecurity", "name": "Cybersecurity", "url": "https://update.dsesecurity.com/topic/cybersecurity/" }, { "slug": "it", "name": "IT", "url": "https://update.dsesecurity.com/topic/it/" } ], "author": { "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/#editorial-team", "type": "Organization" }, "publisher": { "name": "Detection Systems & Engineering", "url": "https://dsesecurity.com/" }, "published_at": "2026-10-30T06:47:17+00:00", "modified_at": "2026-10-30T06:47:28+00:00", "reviewed_on": "2026-10-30", "reading_minutes": 3, "word_count": 526, "potentially_affected": "Windows Wazuh agents using File Integrity Monitoring for registry entries and considering exact-content change reports.", "dse_recommendation": "DSE recommends a value-type and content-need review before enabling exact registry change reporting on a bounded key population.", "primary_source": { "name": "Wazuh — Windows Registry monitoring", "url": "https://documentation.wazuh.com/current/user-manual/capabilities/file-integrity/windows-registry-monitoring.html", "published_on": null, "authority": "documentation.wazuh.com" }, "publishing_principles": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/", "usage_info": "https://update.dsesecurity.com/usage/", "copyright_notice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.", "content_html": "

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.

\n

Source fact: documented behavior

\n

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

\n

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.

\n

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

\n

What the source does not establish

\n

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.

\n

Applicability questions

\n\n

DSE recommendation: controlled next steps

\n

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

\n

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

\n
    \n
  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. \n
  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. \n
  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.
    4. \n
\n

Verification and evidence

\n

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.

\n

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.

\n

Official references

\n\n

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

\n", "content_text": "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.\nSource fact: documented behavior\nThe Windows Registry monitoring guide describes periodic registry scans and says newly created matching keys are scanned from the next scheduled FIM scan.\nFor 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.\nThe guide warns that this reporting stores monitored copies in the agent’s registry diff directory and increases storage use.\nWhat the source does not establish\nThis 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.\nApplicability questions\n\nWhich exact keys and value types are in scope?\nDoes the investigation need contents or only evidence of change?\nWhat scheduled scan applies to those entries?\nWho approves the local diff-copy population and its capacity?\n\nDSE recommendation: controlled next steps\nThe following steps are DSE recommendations based on the cited source.\nDSE recommends a value-type and content-need review before enabling exact registry change reporting on a bounded key population.\n\nList 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.\nCompare 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.\nPrepare 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.\n\nVerification and evidence\nProposed 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.\nRetain 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.\nOfficial references\n\nWindows Registry monitoring — Wazuh; official product documentation.\n\nSource review completed October 30, 2026. Recheck the official source and deployment-specific applicability before changing production settings.", "content_markdown": "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.\n\n## Source fact: documented behavior\n\nThe [Windows Registry monitoring](https://documentation.wazuh.com/current/user-manual/capabilities/file-integrity/windows-registry-monitoring.html) guide describes periodic registry scans and says newly created matching keys are scanned from the next scheduled FIM scan.\n\nFor 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.\n\nThe guide warns that this reporting stores monitored copies in the agent’s registry diff directory and increases storage use.\n\n## What the source does not establish\n\nThis 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.\n\n## Applicability questions\n\n- Which exact keys and value types are in scope?\n\n- Does the investigation need contents or only evidence of change?\n\n- What scheduled scan applies to those entries?\n\n- Who approves the local diff-copy population and its capacity?\n\n## DSE recommendation: controlled next steps\n\nThe following steps are DSE recommendations based on the cited source.\n\nDSE recommends a value-type and content-need review before enabling exact registry change reporting on a bounded key population.\n\n- 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.\n\n- 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.\n\n- 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.\n\n## Verification and evidence\n\nProposed 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.\n\nRetain 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.\n\n## Official references\n\n- [Windows Registry monitoring](https://documentation.wazuh.com/current/user-manual/capabilities/file-integrity/windows-registry-monitoring.html) — Wazuh; official product documentation.\n\nSource review completed October 30, 2026. Recheck the official source and deployment-specific applicability before changing production settings." }, "json_ld": { "@context": "https://schema.org", "@graph": [ { "@type": "Organization", "@id": "https://dsesecurity.com/#organization", "name": "Detection Systems & Engineering", "alternateName": "DSE Security", "url": "https://dsesecurity.com/", "logo": { "@type": "ImageObject", "url": "https://update.dsesecurity.com/assets/dse-logo-20260812.png?v=1.8.20" } }, { "@type": "Organization", "@id": "https://update.dsesecurity.com/#editorial-team", "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/", "parentOrganization": { "@id": "https://dsesecurity.com/#organization" } }, { "@type": "WebSite", "@id": "https://update.dsesecurity.com/#website", "name": "DSE Updates", "alternateName": "DSE Security Knowledge Hub", "url": "https://update.dsesecurity.com/", "inLanguage": "en-US", "publisher": { "@id": "https://dsesecurity.com/#organization" }, "potentialAction": { "@type": "SearchAction", "target": { "@type": "EntryPoint", "urlTemplate": "https://update.dsesecurity.com/?q={search_term_string}" }, "query-input": "required name=search_term_string" } }, { "@type": "WebPage", "@id": "https://update.dsesecurity.com/updates/scope-wazuh-registry-change-reports-to-supported-value-types/", "url": "https://update.dsesecurity.com/updates/scope-wazuh-registry-change-reports-to-supported-value-types/", "isPartOf": { "@id": "https://update.dsesecurity.com/#website" }, "lastReviewed": "2026-10-30" }, { "@type": "BreadcrumbList", "@id": "https://update.dsesecurity.com/updates/scope-wazuh-registry-change-reports-to-supported-value-types/#breadcrumbs", "itemListElement": [ { "@type": "ListItem", "position": 1, "name": "DSE Updates", "item": "https://update.dsesecurity.com/" }, { "@type": "ListItem", "position": 2, "name": "Cybersecurity", "item": "https://update.dsesecurity.com/topic/cybersecurity/" }, { "@type": "ListItem", "position": 3, "name": "Scope Wazuh registry change reports to supported value types", "item": "https://update.dsesecurity.com/updates/scope-wazuh-registry-change-reports-to-supported-value-types/" } ] }, { "@type": [ "Article", "TechArticle" ], "@id": "https://update.dsesecurity.com/updates/scope-wazuh-registry-change-reports-to-supported-value-types/#article", "identifier": "https://update.dsesecurity.com/updates/scope-wazuh-registry-change-reports-to-supported-value-types/", "url": "https://update.dsesecurity.com/updates/scope-wazuh-registry-change-reports-to-supported-value-types/", "headline": "Scope Wazuh registry change reports to supported value types", "description": "Distinguish registry change detection from exact-content reports. Review the documented supported value types…", "abstract": "Distinguish registry change detection from exact-content reports. Review the documented supported value types, scheduled-scan boundary and local diff-copy storage before enabling Wazuh report_changes.", "articleBody": "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.\nSource fact: documented behavior\nThe Windows Registry monitoring guide describes periodic registry scans and says newly created matching keys are scanned from the next scheduled FIM scan.\nFor 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.\nThe guide warns that this reporting stores monitored copies in the agent’s registry diff directory and increases storage use.\nWhat the source does not establish\nThis 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.\nApplicability questions\n\nWhich exact keys and value types are in scope?\nDoes the investigation need contents or only evidence of change?\nWhat scheduled scan applies to those entries?\nWho approves the local diff-copy population and its capacity?\n\nDSE recommendation: controlled next steps\nThe following steps are DSE recommendations based on the cited source.\nDSE recommends a value-type and content-need review before enabling exact registry change reporting on a bounded key population.\n\nList 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.\nCompare 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.\nPrepare 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.\n\nVerification and evidence\nProposed 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.\nRetain 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.\nOfficial references\n\nWindows Registry monitoring — Wazuh; official product documentation.\n\nSource review completed October 30, 2026. Recheck the official source and deployment-specific applicability before changing production settings.", "datePublished": "2026-10-30T06:47:17+00:00", "dateModified": "2026-10-30T06:47:28+00:00", "mainEntityOfPage": { "@id": "https://update.dsesecurity.com/updates/scope-wazuh-registry-change-reports-to-supported-value-types/" }, "inLanguage": "en-US", "isAccessibleForFree": true, "author": { "@type": "Organization", "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/#editorial-team" }, "publisher": { "@id": "https://dsesecurity.com/#organization" }, "image": { "@type": "ImageObject", "@id": "https://update.dsesecurity.com/updates/scope-wazuh-registry-change-reports-to-supported-value-types/#primaryimage", "url": "https://update.dsesecurity.com/assets/editorial/cyber-defense-social-v2.jpg?v=1.8.20", "contentUrl": "https://update.dsesecurity.com/assets/editorial/cyber-defense-social-v2.jpg?v=1.8.20", "width": 1200, "height": 630, "caption": "Scope Wazuh registry change reports to supported value types" }, "articleSection": [ "Cybersecurity", "IT" ], "keywords": [ "Cybersecurity", "IT", "Guide", "Advisory priority" ], "genre": "Guide", "about": [ { "@type": "Thing", "name": "Cybersecurity", "url": "https://update.dsesecurity.com/topic/cybersecurity/" }, { "@type": "Thing", "name": "IT", "url": "https://update.dsesecurity.com/topic/it/" } ], "wordCount": 526, "timeRequired": "PT3M", "publishingPrinciples": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/", "usageInfo": "https://update.dsesecurity.com/usage/", "copyrightHolder": { "@id": "https://dsesecurity.com/#organization" }, "copyrightNotice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.", "citation": { "@type": "CreativeWork", "name": "Wazuh — Windows Registry monitoring", "url": "https://documentation.wazuh.com/current/user-manual/capabilities/file-integrity/windows-registry-monitoring.html" } } ] } }