Patch Management Release 3.9

August 31, 2025

Implementation of QQL Token Standardization

We have now implemented Qualys Query Language (QQL) token standardization across all Qualys applications. As part of this enhancement, both common and Patch Management-specific tokens are updated with new token names that follow a standard consistent nomenclature.

The new token format follows the syntax: entity.attribute
For example, in the new token, patch.architecture, patch is the entity, and architecture is the attribute.

Key Enhancements:

Standardized Token Naming: The patch, assets, jobs, and views tokens now follow the standardized naming convention. The tokens common to all Qualys applications have also been updated.
Search Bar Updates: Only the new tokens are displayed in the auto-suggestion in the search bars within the UI. However, if you type the old token name manually, the QQL query still works. The old tokens will not be visible in the auto-suggestions on the UI.
Backward Compatibility: The existing Dashboard widgets and Saved Search Queries will continue to support the old tokens in edit mode.
Improved Interoperability: The standardized tokens make it easier to copy and reuse the search query from one application to another, eliminating the need to remember multiple token names for different applications and similar searches.

For the complete list of old and new token mapping, see Old and New Token Mappings.

Enhancement to the New Updates Option

We have now enhanced the look and structure of the New Updates option on the Patch Management application. This option displays new features, enhancements to existing features, and API updates released in the new version of Patch Management. The Learn More link points to the current version of the release notes.
The New Updates window now appears as a pop-up message for the first five logins to the application. If you click the Do not show this again checkbox, the window does appear on the next login. To continue to access this option, click Help > What's New.

Define a Default Job for Inactive and Newly Activated Assets

You can now define and execute a default deployment patch job for the Windows, Linux, and Mac assets that are newly activated or have been inactive for a while. To create this job, navigate to the Jobs > Default Jobs tab.

Key Features

Runs on assets that have been inactive for a defined number of days.
Runs on newly activated assets that are part of the asset tags specified in the default job.
Supports adding only asset tags and not individual assets explicitly to the job.
Allows exclusion of asset tags.
Provides options to clone, edit, and delete the job.

The default deployment jobs have simplified settings for ease of automation. These jobs are used for deployment of patches on the inactive assets along with the newly activated assets.

The following configurations are not available in this job type:

Notification settings
Job scheduling options
Opportunistic patch downloads

Customize CVE Selection for Mitigation Jobs

You can now select specific CVEs associated with a QID when creating mitigation jobs for the Windows or Linux platform. This enhancement offers greater flexibility and control, allowing you to mitigate only the CVEs you intend to mitigate, rather than all CVEs associated with the QID.

Previously, mitigation was applied to all CVEs linked to the selected QID by default.

Support Added for Ubuntu 24.10, 25.04, and RHEL 10 Linux Assets

We have now supported patching and mitigation along with rollback operation for the Ubuntu 24.10, 25.04, and RHEL 10 Linux assets across supported architectures. The RHEL 10 Linux operating system also supports non-security updates.

This support depends on the Cloud Agent version 7.2.38.

Asset Data Retention Policy for Deactivated Assets

With the new asset data retention policy, we now retain the asset data of the deactivated assets for 45 days from the date of deactivation.

Previously, if the Patch Management, Mitigation or Isolation applications were disabled, the asset data became inaccessible. Also, if the assets were deactivated, the associated data was lost.

With this enhancement, you can still view the deactivated assets on Job progress page which were part of the job before deactivation. You can request to restore the asset data and jobs data associated with the deactivated assets within 45 days of deactivation. This capability helps recover lost data, enabling smoother operations and preventing data loss.

To request data recovery, you must contact your Technical Account Manager (TAM).

Issues Addressed

The following reported and notable customer issues are fixed in this release.

Component/Category	Description
PM - Licensing	An issue was observed in which users received no license error while deploying patches on certain assets. This issue occurred because the Cloud Agent was uninstalled from the assets, but the inactive assets were still visible on the Patch Management application. The issue is now fixed with the removal of the stale assets from the Patch Management application.
PM - Reports	An issue was fixed in which the asset report generation failed when the search query included QQL tokens, which made the query too long.
PM - Job Windows	An issue was fixed in which the users did not receive the deployment job completion email notification.
Patch	An issue was fixed where an Unauthorized Access error occurred on the Job Progress page when users refreshed the page or navigated to other consoles. This error occurred although users had the appropriate permission to access the page.
Patch UI Jobs	An issue was fixed where, after a Manager user changed the deployment job owner's name, the owner's field displayed a dash (-) instead of the updated new name. After the new job owner modified the job, the owner's name reverted to the previous owner's name instead of the new owner's.
MTG - Job Windows	An issue was fixed where, during mitigation job creation through the VMDR > Prioritization workflow, assets incorrectly displayed a Not Applicable status.

API Release Updates

For more details on the API updates for this release, see Patch Management API Release 3.9.