Auto Patching Behavior, Limitations, and Best Practices

Overview

Auto Patching in Cyrisma is an automated remediation mechanism that applies patches for supported third-party applications after vulnerabilities are detected during scanning. The feature is designed to reduce manual effort, improve remediation speed, and maintain consistent security posture across endpoints.

This article explains how Auto Patching behaves, its intentional limitations, and best practices for using it safely and effectively.

How Auto Patching Works

Auto Patching operates on a scan-driven model.

The process follows this sequence:

1. An internal authenticated vulnerability scan runs on an endpoint

2. The scan detects a vulnerability tied to a supported third-party application

3. Cyrisma determines whether the application is patchable

4. If Auto Patching is enabled, the patch is queued automatically

5. The patch is applied after the configured installation delay

6. Patch results are recorded in Patch History

Auto Patching does not run independently of scanning. It is fully dependent on fresh scan data.

Supported Scope

Auto Patching applies only to:

• Supported third-party applications

• Endpoints scanned using internal authenticated scans

Auto Patching does not apply to:

• Windows operating system updates

• Unsupported or custom applications

• Linux or macOS operating system vulnerabilities

• External vulnerability scan results

Windows OS patching must be managed manually or through other tooling.

Timing and Execution Behavior

Auto Patching timing is governed by Patch Manager configuration.

Key behaviors include:

• Patches are applied only after the Auto Patch Installation Delay expires

• Delays begin at the time the vulnerability is detected, not scan start time

• Blackout Hours override both manual and automatic patch execution

• If a host is offline, patches are applied when the host checks in

Auto Patching does not retry indefinitely. Successful execution requires the agent to be online and functional.

Relationship to Mitigation Plans

Auto Patching and mitigation plans are intentionally decoupled.

Important distinctions:

• Auto Patching performs remediation

• Mitigation plans track and document remediation actions

• Auto Patching does not automatically complete mitigation plan items

• Mitigation plans do not update dynamically after patching

To reflect remediation in a mitigation plan:

• A new scan must be run

• The updated scan results must be reviewed

• Actions must be documented manually within the mitigation plan

This separation ensures mitigation plans remain accurate historical records.

Known Limitations

Auto Patching has several intentional limitations that should be clearly understood.

No Rollback Capability

Once a patch is applied:

• Cyrisma cannot automatically undo the patch

• Rollbacks must be handled manually on the endpoint

• This applies to both manual and auto-applied patches

Because of this, Auto Patching should be enabled only where rollback risk is acceptable.

No Server vs Workstation Separation

Auto Patching does not currently distinguish between:

• Servers

• Workstations

All eligible endpoints are treated equally unless excluded using configuration controls.

This makes host exclusions and blackout hours critical in mixed environments.

Scan Dependency

Auto Patching requires:

• Successful internal authenticated scans

• Updated scan data

If scans are not running regularly:

• Auto Patching will not trigger

• Vulnerabilities may remain unpatched

Third-Party Only

Auto Patching is limited to third-party applications supported by Cyrisma.

It does not:

• Patch Windows KB updates

• Modify operating system configurations

• Address configuration-based vulnerabilities

Best Practices for Auto Patching

Enable Auto Patching Gradually

• Start with low-risk applications

• Validate patch behavior before broad rollout

• Monitor Patch History closely during initial use

Use Installation Delays Strategically

• Set delays to allow validation and approval

• Use longer delays in production environments

• Adjust delays based on operational maturity

Configure Blackout Hours Early

• Define blackout windows before enabling automation

• Prevent patching during business-critical periods

• Ensure blackout windows align with maintenance policies

Use Exclusions Thoughtfully

• Exclude sensitive systems using the No Install List

• Exclude software managed by other tools

• Review exclusions periodically

Maintain Regular Scanning

• Schedule internal authenticated scans consistently

• Ensure agents remain online and healthy

• Treat scanning as a prerequisite for remediation

When Auto Patching Is Not Appropriate

Auto Patching may not be suitable when:

• Strict change control processes exist

• Rollback capability is mandatory

• Servers require manual approval for changes

• Applications are highly customized

In these cases, manual patching combined with mitigation plans may be more appropriate.

Summary

Auto Patching in Cyrisma is designed to automate third-party remediation while preserving control and auditability.

Key characteristics:

• Scan-driven execution

• Third-party application scope

• No automatic rollback

• Decoupled from mitigation plans

When configured correctly and supported by consistent scanning, Auto Patching can significantly reduce remediation effort without sacrificing governance.