AegisPatch™
Patch Windows and Linux servers from one console. Your teams approve each stage. AegisPatch does the work.
Vulnerabilities are ranked by real-world exploit risk. Patches move from Test to Production only when each stage's approver signs off, on evidence. Every server is snapshotted first, production rolls out one server at a time and stops at the first failure, a failed server rolls back automatically, and every selection, approval and patch run is recorded in a tamper-evident audit log. AegisPatch is ready for a proof of concept in your own sandbox, and the validation status below shows exactly what has been tested so far.
Ranked with OSV, the CISA Known Exploited Vulnerabilities list, EPSS and NVD.
Nothing moves to the next stage without the named approver.
Nobody logs into a server. AegisPatch applies, checks, reboots where needed and rolls back.
Every action recorded, with name, time and comment on every approval.
One locked bundle, approved stage by stage
Your patching team chooses the patches. AegisPatch locks them into one bundle and moves it through your environments, and it advances only when each team approves. Production receives exactly what Test approved; new patches go into the next bundle.
Snapshot first
Before any change: an LVM snapshot on Linux, a VM snapshot (Hyper-V or your own script, for example PowerCLI for vCenter), or a boot-disk snapshot in AWS, Azure, Google Cloud or OCI.
Pre-change gates
Supported OS, clean package database, snapshot space, /boot coverage for kernel updates and a healthy baseline are checked before anything is installed.
Evidence before approval
Each approval page shows the automated results first. Failures block approval until they are reviewed.
Promotion gate for production
Production needs explicit approval, and each package must already have been applied successfully on a non-production server within the last 30 days.
Careful production rollout
One server at a time, and Windows failover clusters through Cluster-Aware Updating. The rollout stops at the first failure and that server rolls back automatically.
Checks and reboots
Application checks after every patch
- Lists every package and the exact version the bundle installs, and stops a server whose repository offers a different version.
- Flags changes to shared runtimes such as OpenSSL, glibc, Java, .NET, Python and Node.js.
- Confirms your services are running and their health endpoints respond; if not, the server is rolled back.
- Runs your own checks: HTTP health checks, commands on the servers, service state, and a webhook to your CI tool (Jenkins, GitLab or Azure DevOps need a small adapter in front of them).
- In UAT, each application owner signs off on their own application, after a minimum soak time you set.
- A check that errors or times out counts as failed. Applications without checks are shown as Untested, never as passed.
- Lists processes still using replaced shared libraries, which need a restart to load the fix.
Reboots and downtime
- The commitment is no service downtime, not zero reboots. Some Windows and Linux updates still need a reboot, and AegisPatch schedules those so your services stay available.
- Patch without rebooting where the vendor allows it: Linux package updates with targeted service restarts, vendor live patching for kernels, and Microsoft Hotpatch on supported Windows versions.
- Everywhere else, reboot one node at a time: drain it from the load balancer (F5 BIG-IP, or any load balancer with a command line), reboot, wait for it to come back, health-check and return it before the next one starts. Any failure halts the rollout and leaves that server drained.
- No service downtime needs at least two nodes per critical service behind a load balancer or in a cluster.
Controls and audit evidence
A role for each team
Viewers, auditors, patch selectors, stage approvers (Test, Dev, UAT, Non-prod), application owners, production approvers and platform admins, mapped from your directory groups. Sign-in through your identity provider (OIDC) or directly against Active Directory over LDAPS.
Segregation of duties
The person who requested a production change cannot approve it, a bundle's requester and locker cannot sign off UAT, and a platform admin cannot approve or apply patches. Production approval needs a fresh sign-in within 15 minutes.
Your change process
A ServiceNow change request is created when a bundle is locked and updated at every stage; other tools such as Jira through a webhook.
Tamper-evident audit log
Every real action is written to a SHA-256 hash-chained log that is re-verified on load and before every write. Store its root hash in a system you control, such as your SIEM or write-once storage.
Emergency stop
Pause all patching at once. Pausing needs a reason and is recorded; resuming needs a production approver or platform administrator.
Reports for audit
PDF compliance summary, patch deadlines, exceptions and per-bundle reports, on demand or on a schedule by folder or email, plus a CSV export of the whole estate.
AegisPatch produces evidence useful for vulnerability-management controls such as PCI DSS v4.0 6.3.3, ISO/IEC 27001:2022 A.8.8 and SOC 2 change management. It does not make you compliant on its own, and the product has not yet been independently audited or penetration-tested.
Runs inside your network. Sends nothing to us.
Data and access
- Runs on a server inside your data centre or private cloud, managed by your team.
- Collects server name and address, OS version, installed package and update versions, patch and health-check results, and the audit log. No business or customer data from your applications.
- No telemetry, licence check or usage reporting. Vulnerability feeds are fetched online only if you turn that on (off by default).
- Credentials can be fetched at run time from HashiCorp Vault or CyberArk; they are cached in memory for 5 minutes and never written to disk or logged.
Deployment
- Agentless: Linux (Ubuntu, Debian and the RHEL family) over SSH with strict host-key checking; Windows Server 2016 to 2025 and Windows 10/11 over OpenSSH or WinRM over HTTPS with Kerberos.
- Offline mode runs with no outbound internet, using checksummed file imports of vulnerability feeds and your internal mirrors (apt mirrors, Red Hat Satellite, Oracle ULN, WSUS).
- Sign-in through Microsoft Entra ID, AD FS, Okta or Ping, or direct LDAPS to Active Directory.
- Patches the operating system only. Firmware, BIOS and hardware drivers are out of scope.
What to expect by operating system
| Operating system | Patching without a reboot | Still needs a reboot |
|---|---|---|
| Linux packages | Yes, with service restarts | No |
| Ubuntu LTS kernel | Canonical Livepatch (Ubuntu Pro) | Fixes Livepatch does not cover |
| RHEL kernel | Red Hat kpatch | Fixes without a live patch |
| Oracle Linux | Oracle Ksplice (Premier Support) | One restart when first enabling user-space patching |
| Windows Server 2025 | Microsoft Hotpatch via Azure Arc | Quarterly baseline updates |
| Windows Server 2016-2022 (other editions) | No | Most cumulative updates, handled by rolling reboots |
Systems the vendor no longer patches are reported as end of life, never shown as patched. Windows Hotpatch needs Azure Arc or Intune, so it is not available in a network with no outbound internet.
How a proof of concept runs
We agree the scope with you before anything is installed. Nothing touches a production server during the POC.
Scope
Pick a handful of test servers (Linux, Windows or both), the applications on them and who approves each stage.
Install
AegisPatch runs on one server in your network, signs in through your identity provider and connects to the test servers over SSH or WinRM. No agents.
Scan
A read-only scan lists the missing fixes on each server, ranked by exploit risk.
Patch and roll back
Patch the test servers through the approval stages, and see the snapshot, health checks and automatic rollback work on your own systems.
Review
Your auditors review the audit log and PDF reports, and we agree together what a production rollout would need.
Validation status
This is where each part stands today. The POC validates the parts you use on your own servers; production use follows a successful POC.
| Area | Status |
|---|---|
| Ubuntu / Debian: scan, snapshot, patch, health check, automatic rollback | Built and tested against real Ubuntu 22.04 output; full cycle being validated on VMs |
| RHEL, Rocky, Alma, CentOS Stream, Oracle Linux, Fedora | Built; validation on real hosts in progress |
| Windows Server and Windows 10/11, live patching, rolling reboots | Built and tested against simulated systems; validation on real hosts in progress |
| Single sign-on, Active Directory, Vault, CyberArk, ServiceNow | Built and tested against simulated systems; validation against real services in progress |
| Cloud boot-disk snapshots and discovery (AWS, Azure, Google Cloud, OCI) | Built and tested against simulated cloud APIs; validation in real accounts in progress |
| IBM AIX, Oracle Solaris, BSD | Not built |
IBM AIX, Oracle Solaris and BSD are not part of a POC today.
Try AegisPatch with your own data
See the sample demo first, then tell us about your environment. We agree the scope with you before anything is installed.