--- title: "February 2026 monthly release" description: "What changed in Guardian Classic in the February 2026 monthly release." product: "Guardian" edition: "Classic" type: "reference" url: "https://docs.cloudhouse.com/guardian/classic/what-s-new/1-current-release/monthly/february-2026/" --- # February 2026 monthly release For help upgrading to the latest version, contact your Cloudhouse Representative. The following table describes each component available to upgrade within this release of Guardian. For more information on the known issues currently present within Guardian, see [Known Issues](https://docs.cloudhouse.com/guardian/classic/known-issues/known-issues/index.md). Applies to: `Guardian Classic` !!! tip To access a more simplified view of the changes included within this release, see [February 2026 Changelog.pdf](https://docs.cloudhouse.com/guardian/classic/assets/files/guardian/what-s-new/1-current-release/changelog/february-2026-changelog.pdf). | Release Date | Guardian Platform | Guardian Web | | --- | --- | --- | | 26th February 2026 | V4 | V3.63.0 | ## Guardian web application v3.63.0 Here's what's included in V3.63.0 of the Guardian web application as part of the February 2026 monthly release. ### New features The following new features are included within this release of the Guardian web application. #### New best practice Windows public policy As part of our continued efforts to improve security and guidance, we have introduced a pre-defined 'Windows Best Practice' policy for Windows 10/11 nodes that is automatically applied to the 'Windows' dynamic node group. The policy is public, non-editable, and shared across all organisations within the **Benchmarks** tab (**Control** > **Benchmarks**). For more information on public policies, see [Public Policies](https://docs.cloudhouse.com/guardian/classic/control/policies/policies/index.md#public-policies). !!! tip Whilst the policy cannot be edited directly, you can clone the policy into a private, editable copy by exporting and re-importing the policy with your changes. For more information, see [Export / Import Policy](https://docs.cloudhouse.com/guardian/classic/control/policies/export-import-policy/index.md). ![Windows best practice](https://docs.cloudhouse.com/guardian/classic/assets/images/guardian/whats-new/2026/february/windows-best-practice.png) If you have any new or existing Windows nodes in your estate, they are automatically added to the dynamic 'Windows' node group, and will now have the 'Windows Best Practice' policy applied by default. As part of this release, each check contained within the policy is to be run during each scan of a Windows node, with the [node scan results](https://docs.cloudhouse.com/guardian/classic/inventory/monitored/nodes/node-scan-results/index.md) indicating whether the checks passed or failed - as demonstrated in the screenshot below. !!! tip For more information on the node scan results page and assessing policy compliance, see [Policy Compliance](https://docs.cloudhouse.com/guardian/classic/inventory/monitored/nodes/node-scan-results/index.md#policy-compliance). ![Windows policy pass fail](https://docs.cloudhouse.com/guardian/classic/assets/images/guardian/whats-new/2026/february/windows-policy-pass-fail.png) Once the policy has been run, you can generate a policy report to view the results of each passing and failing check across each Windows node in your estate, to see if they are compliant with our best practice guidelines (which are outlined in the below section). ![Policy report](https://docs.cloudhouse.com/guardian/classic/assets/images/guardian/whats-new/2026/february/policy-report.png) **The following list outlines the checks that are included within the new 'Windows Best Practice' policy:** !!! note Since the checks define a recommended configuration state that should be present during the node scan (e.g. anti-malware **is** enabled); the check will fail if that recommendation is not met (e.g. anti-malware **is not** enabled), or pass if the recommendation is met (e.g. anti-malware **is** enabled). - **Antimalware Enabled** – It is recommended that anti-malware is enabled. - **Antimalware Realtime Protection Enabled** – It is recommended that anti-malware realtime protection is enabled. - **Password History Length** – It is recommended that password history length is at least 24 passwords. - **Password Minimum Length** – It is recommended that the password is at least 14 characters long. - **Failed Lockout Threshold** – It is recommended that the fails login threshold is no more 10 failed logins. - **Guest Account Enabled** – It is recommended that the Guest user account is not enabled. - **Firewall - Domain Profile Enabled** – It is recommended that the firewall is enabled for all profiles. - **Firewall - Private Profile Enabled** – It is recommended that the firewall is enabled for all profiles. - **Firewall - Public Profile Enabled** – It is recommended that the firewall is enabled for all profiles. - **Days Since Last Patch** – It is recommended that the system is patched within the past 30 days. - **SecureBoot Enabled** – It is recommended that SecureBoot is enabled. - **OS Drive Encrypted** – It is recommended that the OS drive is encrypted. #### Azure Key Vault as an integration type As part of this release, we have introduced a new integration type, Azure Key Vault, to the **Integrations** tab (**Control** > **Integrations**). This integration allows you to connect your Guardian instance to an Azure Key Vault environment and synchronise secret data stored within it. Once added, the integration behaves like other Guardian integrations, such as Azure or Amazon Web Services (**AWS**), enabling you to configure credentials, manage the integration from the **Integrations** tab, and review related activity through the **View Events** drop-down menu for auditing and troubleshooting. !!! tip For more information on this new integration type, see [Azure Key Vault Integration](https://docs.cloudhouse.com/guardian/classic/control/integrations/azure-key-vault-integration/index.md). ![Azurekeyvaultintegration](https://docs.cloudhouse.com/guardian/classic/assets/images/guardian/whats-new/2026/february/azurekeyvaultintegration.png) #### Azure Key Vault as a credential source A new credential source, **Azure Key Vault**, is now available when selecting **Password** as the credential type when adding a Linux or Network device node from the **Add Nodes** tab (**Inventory** > **Add Nodes**). When selected, Guardian retrieves the username and secret directly from your organisation’s [Azure Key Vault Integration](https://docs.cloudhouse.com/guardian/classic/control/integrations/azure-key-vault-integration/index.md), allowing you to choose from a list of your stored credentials by selecting an option from the **Azure Key Vault** drop-down list. This enhancement centralises credential storage, reduces manual entry, and adds support for secure, cloud‑hosted credential retrieval when adding nodes. !!! tip For more information on this new credential source, see [Azure Key Vault Credentials](https://docs.cloudhouse.com/guardian/classic/inventory/credentials/azure-key-vault-credentials/index.md). ![Azurekeyvault](https://docs.cloudhouse.com/guardian/classic/assets/images/guardian/whats-new/2026/february/azurekeyvault.png) ### Other enhancements The following additional enhancements are included within this release of the Guardian web application. #### Improved visibility of passing/Failing policy checks When a policy is run during a [node scan](https://docs.cloudhouse.com/guardian/classic/inventory/monitored/nodes/node-scan-results/index.md), you can see whether individual checks have passed or failed by selecting a configuration item highlighted in green (pass) or red (fail). To improve the visibility of these checks, selecting a configuration item opens a side panel on the right‑hand side of the screen that provides a breakdown of each check. ![Windows policy pass fail2](https://docs.cloudhouse.com/guardian/classic/assets/images/guardian/whats-new/2026/february/windows-policy-pass-fail2.png) For passing checks, the panel now includes a **View** option, which displays further detail about what the check consists of and how its pass or fail state is determined. For failing checks, a **Show Details** option is displayed instead, along with a **View notes** option within the check background, allowing you to review additional failure information. #### Policy UI consistency improvements This enhancement improves clarity and usability when creating and editing policy checks by addressing inconsistent save interactions and minor visual issues in conditional drop-downs. !!! tip For more information on how to edit a policy, see [Edit Policy](https://docs.cloudhouse.com/guardian/classic/control/policies/edit-policy/index.md). ![Policy ui improvements](https://docs.cloudhouse.com/guardian/classic/assets/images/guardian/whats-new/2026/february/policy-ui-improvements.png) ##### Consistent save and cancel actions Editing different fields within a policy check currently displays different save mechanisms, such as labels, icons, or buttons, which can be confusing. All editable fields have now been updated to use clear and consistent '**Save**' and '**Cancel**' buttons, with no alternative or implicit save actions. ##### Correct display of comparison operators When selecting comparison operators (`>`, `>=`, `<`, `<=`) for conditional policy checks, the collapsed drop-down can truncate `>=` and `<=`. This has now been fixed so the selected value is always fully visible across all policy editing contexts. !!! tip For more information on conditional policy checks, see [Checks](https://docs.cloudhouse.com/guardian/classic/control/policies/build-custom-policy/index.md#checks). ### Fixed issues The following issues have been fixed within this release of the Guardian web application. **Affects Versions**: V3.59 : **Fix Version**: V3.63.0 #### Problem On the **Change Report** tab (**Reports** > **Change Report**), filtering results using the **Change Request ID** field could lead to inconsistent and misleading behaviour. When a **Change Request ID** was entered and a matching approved change selected, clearing the filter using the **[x]** icon did not fully reset the filter state. Instead: !!! tip For more information on approving changes, see [Approve Change](https://docs.cloudhouse.com/guardian/classic/reports/change-report/manual-change-reconciliation/index.md#approve-change). - The results list displayed 'All Approved', implying that all approved changes were being shown, even though the UI state was not updated correctly. - Selecting 'All Approved' caused the report to display zero results. - Clearing 'All Approved' using the **[x]** icon reverted the report to the previous filter rather than fully clearing it. - In some cases, the only way to remove the filter was to manually delete text from the **Change Request ID** field. This resulted in filters appearing active or inactive incorrectly, and made it difficult to understand or reset the current filter state. #### Solution The **Change Request ID** filter logic has been updated to ensure consistent and predictable behaviour. You can now: - Select and switch between approved change request IDs without breaking the filter state. - Use the **[x]** icon to fully clear the filter and reset results. - Remove filter options cleanly from the results list, with the UI updating correctly at each step. These changes ensure the **Change Report** accurately reflects the active filter state at all times and can be reset without manual intervention. **Affects Versions**: V3 (onwards) : **Fix Version**: V3.63.0 **Problem** : In the **Monitored** tab (**Inventory** > **Monitored**), when hovering your cursor over a node with a long name, a tooltip is displayed with the full name of the node. However, if the new **Monitored** skin was enabled, only the first 70 characters of the node's name was being displayed in the hover tooltip. **Solution** : We have updated the logic in the new **Monitored** skin, enabling the hover tooltip to wrap and truncate to fit any node's name, regardless of the character count. Now, when hovering your cursor over a node within the new **Monitored** tab, a tooltip is displayed with the full node name as expected. !!! note To enable the new Monitored skin, contact your Cloudhouse Representative. **Affects Versions**: V3 (onwards) : **Fix Version**: V3.63.0 #### Problem On the [Job Schedule](https://docs.cloudhouse.com/guardian/classic/control/job-schedule/job-schedule/index.md) tab (**Control** > **Job Schedule**), filtering the list of scheduled jobs was resulting in a page timeout and console error. !!! note This error was occurring when disabling an enabled job, enabling a disabled job, and changing the filter while a job is selected. Complete the following steps to replicate: 1. Remove the 'Disabled' filter (that is enabled by default). A list of the enabled scheduled jobs are displayed. 2. Select the checkbox for any job in the list, then click the **Edit** drop-down and select 'Disable'. ![Disable filter](https://docs.cloudhouse.com/guardian/classic/assets/images/guardian/whats-new/2026/february/disable-filter.png) The **Job Schedule** page then times out and displays zero results. When the selected job was filtered out, Guardian incorrectly continued to treat the filtered-out job as selected. !!! note Additionally, the options in the **Edit** drop-down remained enabled for the job that should not have been available within the UI. #### Solution The **Job Schedule** tab now correctly resets selection state when jobs are enabled, disabled, or filtered. Any selected job that is no longer visible after a filter or state change is automatically deselected, and edit actions are disabled accordingly. Now, you can filter the list of scheduled jobs as expected, with no timeout or console errors. **Affects Versions**: V3.62.0 : **Fix Version**: V3.63.0 **Problem** : On the **Job Schedule** tab, the scheduled job list initially displayed as expected. However, when selecting a scheduled job, or when attempting to edit a scheduled job using the checkbox and clicking **Edit Maintenance Window**, the job schedule failed to display. This prevented users from viewing or modifying the selected scheduled job. **Solution** : The **Job Schedule** tab now correctly loads and displays the selected scheduled job when it is clicked or when the **Edit Maintenance Window** action is used. The job schedule view is consistently rendered, allowing users to edit or inspect scheduled jobs without display issues. !!! note This fixed issue was implemented as part of a hotfix deployed on 20th February 2026.