Configuring Patch Manager

Last updated: December 23, 2025

Overview

Patch Manager configuration in Cyrisma controls how and when supported patches are applied to endpoints after vulnerabilities are detected. These settings apply to third-party application patching and define the automation, timing, exclusions, and maintenance windows used during remediation.

This article explains the available Patch Manager configuration options, how Auto Patching works, and how these settings influence patch behavior across an instance.

This article focuses on configuration concepts and behavior. Detailed patch execution and tracking are covered in separate Patch Manager and Patch History articles.

Where Patch Manager Configuration Lives

Patch Manager configuration is accessed from within a client instance.

Configuration settings apply only to the current instance and affect all endpoints associated with that instance unless explicitly excluded.

Patch configuration does not apply globally across multiple instances.

Patch Configuration Panel

Patch Manager includes a Patch Config option that opens a configuration modal. This modal defines how Cyrisma handles automated and manual patching behavior.

The configuration options include:

  • Auto Patching toggle

  • Auto Patch Installation Delay

  • No Install List

  • Third Party Patch Exclusions

  • Blackout Hours

Each setting influences how patches are queued and executed.

Auto Patching

Auto Patching enables Cyrisma to automatically apply patches for supported third-party applications after vulnerabilities are detected.

When Auto Patching is enabled:

  • Cyrisma queues patches automatically

  • No manual Patch action is required

  • Patch execution follows the configured delay and blackout rules

Auto Patching applies only to supported third-party applications. It does not apply to Windows operating system updates or unsupported software.

Auto Patch Installation Delay

The Auto Patch Installation Delay defines how long Cyrisma waits before applying a patch after a vulnerability is detected.

Available delay options are:

  • 12 hours

  • 24 hours

  • 36 hours

  • 48 hours

  • 72 hours

The delay begins after a successful internal authenticated vulnerability scan identifies a patchable vulnerability.

This delay allows time for:

  • Validation and testing

  • Internal change approval

  • Customer notification

If Auto Patching is disabled, this delay setting has no effect.

No Install List

The No Install List allows administrators to exclude specific host machines from patching.

Behavior:

  • Hosts selected in this list will never receive patches from Cyrisma

  • Applies to both manual and automatic patching

  • The exclusion is instance-specific

This setting is commonly used for:

  • Sensitive servers

  • Legacy systems

  • Devices managed by alternative patching tools

Excluded hosts will continue to appear in scan results but will not receive patch actions.

Third Party Patch Exclusions

Third Party Patch Exclusions allow administrators to prevent Cyrisma from patching specific third-party software across the instance.

Behavior:

  • Selected software will not be patched on any endpoint

  • Applies to both manual and automatic patching

  • Software may still appear as a root cause in scan results

This is commonly used when:

  • Software is managed by a separate update process

  • Vendor-specific update controls are required

  • Compatibility concerns exist

Exclusions do not suppress vulnerabilities. They only prevent patch execution.

Blackout Hours

Blackout Hours define a maintenance window during which patches cannot be applied.

Key behavior:

  • Applies to both manual and automatic patching

  • Patches will not execute during blackout periods

  • Patches cannot be scheduled during blackout periods

Configuration details:

  • Two time values are selected

  • Times are configurable in 30-minute increments

  • The blackout window repeats daily

Blackout Hours are typically used to prevent patching during:

  • Business hours

  • Critical operational periods

  • Maintenance freeze windows

Interaction with Scanning

Patch Manager configuration depends on scanning behavior.

Important considerations:

  • Auto Patching only triggers after an internal authenticated scan

  • Patch eligibility is determined by scan results

  • Changes to configuration do not retroactively apply to completed patches

If scan data is outdated, Auto Patching will not trigger until a new scan completes.

Interaction with Mitigation Plans

Patch Manager configuration does not affect mitigation plan behavior.

Key points:

  • Patching does not automatically update mitigation plans

  • Mitigation plans remain static until a new scan is run

  • Users must document patching actions manually in mitigation plans

Patch Manager handles execution.
Mitigation plans handle governance and documentation.

Configuration Best Practices

  • Enable Auto Patching only for environments with regular scanning

  • Use installation delays to allow validation time

  • Exclude sensitive systems using the No Install List

  • Use software exclusions for externally managed applications

  • Define blackout hours before enabling automation

These practices help prevent disruption while maintaining consistent remediation.

Summary

Patch Manager configuration in Cyrisma defines how automated and manual patching behaves across an instance.

Configuration controls:

  • Whether patches are applied automatically

  • When patches are applied

  • Which hosts and applications are excluded

  • When patching is allowed to occur

Proper configuration ensures predictable, controlled remediation aligned with operational requirements.