What is installed, where
One row per application, with the version SCCM holds, the newest version, and how many machines are behind. Machines checked by their own agent are told apart from ones guessed from the inventory.
For teams that already run SCCM
Third-party patching, with a way back.
PatchNova finds the out-of-date software on your Windows machines, publishes the new versions to Configuration Manager, deploys them to a few machines at a time, and takes a version back off if it goes wrong.
Patching · Overview
| App | In SCCM | Newest | Status | Machines behind |
|---|---|---|---|---|
| Mozilla Firefox | 131.0 | 131.0 | Up to date | 0 / 214 |
| Notepad++ | 8.6.9 | 8.7.1 | Deploying · stage 2 of 4 | 61 / 188 |
| 7-Zip | 23.01 | 24.08 | Published · machines behind | 97 / 203 |
| Wireshark | – | 4.4.0 | Not published | 12 / 12 |
| VLC media player | 3.0.21 | 3.0.21 | Install failures · 3 machines | 3 / 140 |
How it works
Four steps, each one checked before the next.
Patching third-party software through SCCM by hand means packaging, deploying and watching, one app at a time. PatchNova does the routine parts and stops where a person should decide.
Know what is installed
A small agent on each machine reports what is installed and whether it meets the version you want. It only calls out; nothing connects in to it.
Publish to SCCM
When a vendor releases a new version, PatchNova asks the SCCM worker to publish it as an Application, after the installer has been checked.
Deploy in stages
The update goes to a test group first, then the rest, stage by stage. Each stage has a health check and the deployment can be paused or cancelled.
Take it back if needed
If a version causes trouble, a rollback removes it from the machines that took it and puts the previous version back.
What it does
The parts of patching that usually fall between the cracks.
Several sources, not one
Vendor pages, vendor releases, the Evergreen catalog, winget, Chocolatey and Repology are all asked. A version is Confirmed, Agreed or Unconfirmed, and only the first two raise an alert.
What really needs patching
Installed software is ranked by whether a public vulnerability database lists a flaw in it and whether people actually use it, so the first fixes are the ones that matter.
End of life, before it bites
Operating systems and applications are checked against published end-of-life dates, so a product that is about to lose support is a warning today, not a surprise later.
A record for every failed install
Each machine that did not take an update is kept with the error code, what it means and what to do, until it is fixed. Three moves cover most cases: fix the cause, republish, retry.
Automatic, but not unattended
For the apps you choose, publishing and deploying happen by themselves. A hold period and an approval step still apply, and a version that failed once is left for a person.
Deployments
A few machines first. The rest only if they stay healthy.
Pick a model for each deployment: Canary (a small group, then everyone), Blue-Green (two matched halves) or Rolling (waves of growing size). Between stages PatchNova reads the machines' states back from SCCM and judges the result.
- Pause and cancel at any stage, with alerts when a stage stalls.
- Rollback removes the version from the machines that took it, restores the previous one and marks the bad version so nothing installs it again.
- Watch a small pilot for three days with a report each day of restarts, silent machines, errors and conflicts.
1 · 6% of machinesHealthy
2 · 25%Running
3 · 50%Waiting
4 · the restWaiting
Example of a rolling deployment. Each stage must pass its health check before the next one starts.
Safety
Built so that a mistake stays small.
- Nothing connects inwards. Agents and the worker poll the backend. The backend never reaches into your machines or into SCCM.
- Only SCCM installs software. PatchNova asks, SCCM does it, through deployments an administrator asked for.
- Real runs are off until you turn them on. Everything starts as a dry run that reports what it would do.
- You see who did what. Every change and every refused request is in an audit log. The security details are below.
Security
What is built in, and what is not done yet.
PatchNova runs with high rights on your machines and your SCCM server, so it is built to be given as little as possible. Each item says whether it is in use today. We would rather tell you what is missing than have you find out.
Sign-in and roles
Sign in with your Active Directory account over LDAPS, restricted to the groups you name. Read-only logins can look at everything and change nothing: every change is refused and logged. Sessions last eight hours.
Keys that open only what they must
Agents and the SCCM worker hold a machine key that reaches only the endpoints they need. It cannot sign in, read the page's data, start a deployment or change a setting. The administrator key must be a different key, and keys travel in a header, never in a web address.
An agent that cannot be told to run a command
The agent runs as SYSTEM, so what it is sent is data only and every rule is checked again on the machine: local paths under allowed folders only. A policy can make it report something wrong; it cannot make it run anything. Its key file is readable only by administrators and SYSTEM, and it refuses a plain http server address.
SCCM stays in charge of installs
PatchNova never runs an installer or an uninstaller itself. The worker only touches SCCM objects it created, named for PatchNova, and refuses a stage of more than 500 machines. Installers are checked against the vendor's checksum when the vendor publishes one; otherwise HTTPS is what protects the download.
An audit trail
Publishes, deployments, clean-ups, evaluate requests, setting changes and refused requests are written to an audit log, kept for 365 days, and sent to your SIEM as syslog when you have one. Administrators can read it; read-only logins and the machine key cannot.
A hardened server
It runs as a non-root user on a supported Node.js release. Secrets are compared in constant time, weak or placeholder secrets are named at start-up (never their values) and can stop the server from starting, login input is size-limited, requests are rate limited per client, and an error shows a reference instead of the database's own message.
A key of its own for every machine
Today the machines of one environment share a key. The next agent gives each machine its own: a leaked key then speaks for one machine only and can be blocked or reset without touching the others. Each agent also checks in, and the console records whether the check-in was accepted.
Installers checked before they are published
A scan with Microsoft Defender or your own scanner, a signature check against a list of publishers you allow, and an optional hash lookup. A refused installer is never published, and the refusal raises an alert. This is built and switches on with the next release of the SCCM worker.
Independent review and certification
We have reviewed the code ourselves, fixed what we found and written the review down, but no outside firm has audited PatchNova, and it holds no certification such as SOC 2 or ISO 27001. If you need one, ask us where we stand before you plan around it.
How it is tested
PatchNova comes with a repeatable security test suite: scripts that check a running environment against the OWASP Top 10 (2021) and a subset of the OWASP ASVS, and print a pass or fail. They are plain scripts, so your own security team can run the same checks and see the same result.
| Check | What it looks at | OWASP |
|---|---|---|
| Network scan | Every open TCP port, the services behind them and their versions, and known-vulnerability scripts | A05, A06 |
| TLS | Protocol and cipher strength, certificate names and expiry, HSTS, redirect from http to https | A02 |
| Access control | Every protected route refuses a caller who is not signed in; changed request methods and malformed tokens are refused | A01, A07 |
| Weak credentials | Common passwords against the servers' SSH and database logins | A07 |
| Injection | SQL, script, template, path and command payloads sent to every read endpoint, with a read-only account | A03 |
| Rate limiting | Whether a forged forwarding header gets around the request limit | A04, A07 |
| Dependencies | An audit of every production package for known vulnerabilities | A06 |
| Secrets | No live secret in the repository, and the ignore rules really keep them out | A02, A05 |
| Response headers | HSTS, content-type, framing, content-security, referrer and permissions policies | A05 |
| Database exposure | The database port cannot be reached from outside; only the other database server may | A05 |
| Containers | Runs as a non-root user and is not privileged (CIS Docker Benchmark) | A05 |
- Built to be safe to run. The suite never fuzzes or brute-forces anything that changes data, or the real directory sign-in, so a test cannot corrupt records or lock out an account.
- A code and configuration review as well. On 13 October 2026 the code, the container and web-server settings, the agent and the full history were reviewed, with every database query read. This was a review, not a penetration test.
- What that review found. No known-vulnerable package among the 104 production ones, no secret in 304 commits of history, and every query that takes a value is parameterised. It also listed 3 high, 7 medium and 6 low findings. Most are fixed; the rest are tracked, and the cards above say which are still being released.
- It looks for flaws in your software too. PatchNova ranks what is installed on your machines by whether a public vulnerability database lists a flaw in it, so you patch the exposed software first.
Talk to us
See it on your own machines.
PatchNova is early software for teams that already run Configuration Manager. If you would like a walkthrough, or want to say what your patching looks like today, write to us.
info@patchnova.ai