TruRisk™ Eliminate Release 4.2

September 11, 2026

Stop Specific Patches from Deploying with Patch Blocking Rules

You can now create patch blocking rules to prevent specific patches from being installed by your deployment jobs. When a job includes a blocked patch, the patch is not deployed on the assets covered by the rule. This is useful when you want to validate a patch before it reaches production. 

Patch blocking rules are supported on Windows, Linux, and Mac, and are managed separately for each platform. 
To create, edit, and delete a patch blocking rule, the user must have the Manage Patch Blocking Rules permissions. 

Key Benefits

• Prevent selected patches from being deployed, without editing or pausing your existing jobs.
• Test patches on a pilot group of assets before rolling them out to production.
• Target exactly the patches you want to block by using patch QQL, and preview the matching patches before you save the rule.
• Apply a block to specific assets by using tags, or to all assets across your subscription.
• Record a blocking reason for every rule, so the decision is documented for later review.
• Identify blocked patches and the rule that blocked them directly in your job results.

Navigate to Configuration > Patch Blocking Rules to create a blocking rule.  

Improved Visibility into Blocked Patches

Blocked patches are now clearly identified in your deployment job results and in the Patches tab, so you always know which patches were held back and why.

In the patch list for a deployment job, a blocked patch is reported with the status Skipped and the following reason: Blocked by patch blocking rule "Blocked feature update". The patch applies to this asset but was not installed. 

Because the reason includes the rule name, you can identify which rule blocked the patch and review or update that rule directly.

The following are the benefits of the visibility of the job progress: 

• Understand why a patch was skipped, without investigating the job configuration.
• Identify the specific rule responsible for blocking a patch.
• Review all blocked patches in one place and release them when they are ready for deployment.

- You can create a maximum of 10 blocking rules for each platform — Windows, Linux, and Mac. When the limit is reached, the Create Rule option is not available until you delete an existing rule.
- A rule applies to a maximum of 500 most recently published patches that match your criteria.
- The QQL for each rule can contain a maximum of five tags for each rule.
- You can select a maximum of five tags for each rule.

Require Approval Before Patch Jobs Run

You can now add an approval step to your patching process. Reviewers can verify job details before deployment, helping you reduce mistakes and maintain change control. 

When Job Approval Workflow is enabled, patch jobs no longer run immediately when they're saved and enabled. Instead, jobs enter a Pending Approval state until an authorized user reviews and approves them. Every approval, rejection, and comment is recorded in Job Approval History for complete visibility and auditability. The job approval workflow is applicable to Windows, Mac, and Linux platforms for patch deployment, mitigation, isolation, and all rollback jobs. 

Key Benefits

• Enforce Change Control

  Require a second reviewer to validate assets, patches, schedules, and deployment actions before jobs run. Helps reduce deployment errors and strengthen patch governance.

• Review and Approve Jobs

  Submit jobs for approval directly from the job creation workflow. Approvers can review job details, approve deployment, or reject the request with comments. This ensures deployments are reviewed before they reach production.

• Track Every Decision

  View a complete approval history for each job, including approvals, rejections, comments, users, and time stamps. This helps to maintain a clear audit trail for compliance and operational reviews.

• Find Pending Requests Quickly

  Use the Approval Status filter or QQL search to identify jobs awaiting review. This helps approvers act on pending requests faster.

Turn On the Job Approval Workflow

The Job Approval Workflow is optional  and disabled  by default. A Super Admin can enable or disable it in Configuration > Setup using the Job Approval Workflow toggle.

• Off  (default): Jobs run through the existing process with no changes.
• On: All new jobs must be approved before they can be enabled and run.

Two permissions control the workflow:

• Enable Job Approval Workflow: The Eliminate Manage Job Approval permssions allow Super Admins or authorized users to turn the workflow on or off. 
• Job Approval Permission: The Eliminate Job Approver allows designated  reviewers to approve or reject submitted jobs.

Approvers must also have View  Any Job permission for the corresponding job type. For example, a user cannot approve a mitigation job unless they can view mitigation jobs.

Submit, Review, and Track Job Approvals

Gain controlled job approvals, clear review feedback, and a complete audit trail for every deployment decision.

• Save  & Enable submits the job for approval and sets its status to Pending Approval. Save creates the job in a disabled state and lets you submit it later.

• Job owners and co-authors can submit, withdraw, edit, and resubmit approval requests.

• Approvers can review complete job details before choosing to Approve or Reject.

• The Job Approval History tab records all approval actions, comments, and status changes for audit purposes.

• Approvers can quickly find pending requests using the Approval Status filter or QQL search.