Understanding Patch Status, Pending Updates, and Rollbacks

Last updated: December 23, 2025

This article explains how patch status is tracked in Cyrisma, why patches may remain visible after being applied, how pending patches behave when devices are offline, and why patches applied through Cyrisma cannot be automatically rolled back.

How Patch Status Is Determined in Cyrisma

Cyrisma determines patch status based on:

  • Scan results

  • Agent check-ins

  • Operating system feedback after patch application

In some cases, patch status may not update immediately due to system-level requirements or device availability.

Why Patches May Still Appear After Being Applied

Common Cause: Reboot Required

A patch that has been successfully installed may continue to appear in vulnerability results if the device has not been rebooted.

This occurs because:

  • Some patches are not fully applied until a reboot completes

  • The system continues to report the vulnerability until the reboot finalizes the change

Recommended Actions

  1. Confirm the patch was successfully applied using system or patch logs

  2. Reboot the device

  3. Allow time for the agent to check in

  4. Run a new vulnerability scan to refresh status

Manual Rescans and Status Refresh

If patches still appear after a reboot:

  • Initiate a manual vulnerability scan for the affected device

  • Verify that the scan completes successfully

  • Recheck the vulnerability or patch status

This ensures Cyrisma has updated data from the endpoint.

Pending Patches on Offline Devices

Why Patches Remain Pending

If a workstation or server is offline:

  • The agent cannot receive patch instructions

  • The patch remains in a Pending state

Important Notes

  • Pending patches do not expire

  • The patch remains pending until:

    • The device comes back online and checks in, or

    • The patch assignment is manually canceled

Once the device reconnects, the agent automatically attempts to apply the pending patch.

Canceling a Pending Patch

If a patch should no longer be applied:

  • Manually cancel or delete the pending patch assignment in Cyrisma

Canceling a patch prevents it from executing even if the device later reconnects.

This should only be done if the patch is confirmed to be unnecessary or no longer applicable.

Why Patches Cannot Be Automatically Rolled Back

When Cyrisma applies a patch or configuration change:

  • The change is executed at the system level

  • There is no automated rollback mechanism within the platform

This design:

  • Ensures consistent security baselines

  • Prevents partial or unstable reversions

  • Reduces the risk of reintroducing known vulnerabilities

What to Do If a Patch Needs to Be Undone

If a rollback is required:

  1. Identify the specific patch or configuration change

  2. Follow manual remediation steps appropriate for the operating system or application

  3. Contact Cyrisma Support for guidance if needed

Manual rollback is required in all cases.

Best Practices to Avoid Patch Issues

  • Reboot systems after patching unless explicitly stated otherwise

  • Ensure devices are online and checking in regularly

  • Schedule scans after patch windows to refresh vulnerability data

  • Suppress vulnerabilities that should not be auto-patched in sensitive environments

  • Maintain backups before applying significant updates

Summary

  • Patches may remain visible until a reboot and rescan occur

  • Offline devices retain pending patches indefinitely

  • Pending patches execute automatically when devices reconnect

  • Cyrisma does not support automatic patch rollbacks

  • Manual intervention is required to undo applied patches

Understanding patch lifecycle behavior in Cyrisma helps ensure accurate vulnerability reporting and avoids unnecessary troubleshooting.