π¦ Patch Applications
Patch Applications (menu β Patch Management β Patch Applications) is the application
lifecycle console: it shows every application installed on every endpoint, whether it is
up to date or out of date against the vendor's current version, and lets your team
patch applications with an Administrator / Global Administrator authorization step,
scheduling and delay, and automatic version verification afterwards.
1 Β· What you see
π¦ ApplicationsEvery installed application per endpoint, with installed vs latest version
π» EndpointsPer-endpoint summary: how many apps are out of date, up to date, critical
β±οΈ Patch jobsEvery job, its status, who authorized it, and its results
π Vendor catalogWhat each vendor currently ships, available versions + download links
Status is computed by comparing the installed version against the vendor catalog
(e.g. Chrome 116.0 vs the latest 126.0). Applications with no catalog match are marked
unknown. The catalog also records patch importance, whether the update touches the
registry, and whether a reboot is required.
2 Β· How patching works (authorization first)
Step 1
Select what to patch
Tick out-of-date applications (or use Patch all on an endpoint) and press Patch now or Schedule.
Step 2
Review the change preview
ProPera generates a no-side-effect preview showing the exact endpoints and applications, installed β target versions, risk drivers, expected impact, reboot or registry warnings, rollback availability and required verification. No job or approval exists yet.
Step 3
Choose when
Immediate β run as soon as authorized Β· Schedule β pick a date & time Β· Delay β run N minutes from now. Add a note (e.g. change window) if useful.
Step 4
Administrator authorizes
After the preview is accepted, the job is created. If you are an Administrator / Global Administrator it is authorized immediately. Otherwise an approval request is sent to the Administrators (and to Teams when configured) β only they can Authorize or Reject. Rejected jobs are cancelled.
Step 5
Execute
Once authorized, the job uses the configured deployment channel. In demo mode the flow is simulated; in live mode ProPera records a clear failure when Intune or another deployment channel is not connected rather than claiming success. Scheduled jobs run automatically when due.
Step 6
Verify versions
After execution the installed version is re-checked against the catalog and the application is marked up to date only when verification succeeds. Use Verify versions to re-scan at any time; re-evaluate the related vulnerability where applicable.
β οΈ Registry warning: some updates (e.g. 7-Zip, Java, Adobe Reader) touch the Windows registry.
ProPera flags this in the change preview before creating the job and never modifies the registry silently.
3 Β· Change preview and verification
The preview is a dry run of the patch plan, not a deployment. It reports the target scope, risk score and drivers, affected endpoints and applications, expected downtime, authorization requirement, rollback limits and verification checklist. A preview is recorded as a dry-run audit event but creates no PatchJob or approval.
A successful API response or deployment command is not enough to claim success. The installed version must be confirmed after execution; where a vulnerability is linked, its status must be re-evaluated after the inventory re-scan.
4 Β· Live vs demo mode
| Demo mode | Live (Microsoft) mode |
| Inventory | Realistic sample applications on the demo endpoints | Pulled from Microsoft Defender software inventory when connected; re-scanned by the worker |
| Execution | Simulated β versions update instantly so you can see the full workflow | Deployment intent + verification recorded; pushing to endpoints uses Intune / SCCM / your deployment tooling |
| Authorization | Identical workflow | Identical workflow β Administrator / Global Administrator only |
5 Β· Where else it shows up
- Dashboard β Application patch posture card (out-of-date apps, endpoints needing patches, pending authorizations, scheduled jobs).
- Compliance β the Unpatched endpoints card links straight to Patch Applications; patching posture feeds the continuous-compliance evidence.
- System Logs β every step (request, authorize, reject, execute, verify, cancel) is recorded with actor, role and result.
- REST API β
/api/patches/jobs/preview generates a no-side-effect change preview; /api/patches/* also provides overview, apps, endpoints, catalog, jobs and verification for integration and automation.
6 Β· Who can do what
| Action | Viewer / Analyst | Administrator / Global Admin |
| View inventory, catalog, jobs | β
| β
|
| Create a patch job (immediate / scheduled / delayed) | β
(requires admin authorization) | β
(auto-authorized) |
| Authorize / reject a patch job | β | β
|
| Execute, verify, cancel a job | β
(after authorization) | β
|
Permission notes: creating jobs requires view_vulnerabilities; authorizing requires
an Administrator / Global Administrator role (the API enforces this even if a non-admin calls the
endpoint directly). Every action is audited.