Request Demo
ZENQIX Remediate
Preview

Patch management

A verification-led patch lifecycle is under active engineering: discover, approve, deploy, restart where required, rescan and verify.

AvailabilityPreview
WorkflowDiscover → Act → Verify → Prove
Evidence model6 evidence elements
EvaluationAcceptance checklist
Operational need

What the administrator needs to solve.

Patch dashboards often report that an installation command ran, but operations teams need to know whether the endpoint actually reached the intended patch state.

Current approach

How ZENQIX handles it.

ZENQIX is building patching around explicit phases and post-install evidence, with maintenance windows, canary rollout and reboot-aware verification.

Workflow

Requested action and verified outcome stay separate.

01Discover missing update
02Evaluate target and policy
03Approve/test
04Deploy
05Handle reboot requirement
06Rescan
07Verify installed state
08Record evidence
Capability

What is currently in scope.

Patch policy model

Deployment phases

Maintenance windows

Canary/blast-radius controls

Verification state

Reboot-required state

Platform status

Availability by operating system.

WindowsPreview

Framework and fixtures exist; physical Windows Update execution remains pending.

macOSPreview

Framework exists; software-update physical execution remains pending.

LinuxPreview

Framework exists; package-manager physical execution remains pending.

Synthetic product model

Inspect the state the UI needs to expose.

This panel uses synthetic data. A genuine ZENQIX Endpoint screen can replace it only after sanitization and publication approval.

Open Product Proof
ZENQIX Endpoint · Patch managementPreview
Requested / observed stateCapability-specific endpoint state
EvidenceTimestamped, bounded and tenant scoped
VerificationShown separately from execution

Security

  • Maintenance-window enforcement
  • Canary controls
  • Policy approval boundaries
  • No false success when verification is missing

Evidence

  • Patch identifier
  • Target state
  • Execution attempt
  • Observed installed state
  • Verification time
  • Reboot requirement

Technical detail

  • Preview means engineering architecture and isolated tests exist; it does not mean generally available physical patch execution
FAQ

Technical questions for this capability.

Is ZENQIX patch management GA?

No. It remains Preview until provider-specific physical QA and release acceptance are complete.

Why separate execution from verification?

Because a successful installer invocation is not proof that the intended update is actually present afterward.

Evaluate patch management in your environment.

Use the capability matrix and the written acceptance checklist to confirm whether the current status matches your pilot needs.