Keep machines patched

Patch Management

The operational patch view: what is missing, critical, failed, or needs a reboot across the fleet, built from the structured scans agents report rather than scraped text. SentinelOps has it so patch exposure is a single honest number instead of a per-machine guess — offline or never-scanned devices show as offline/unknown, never falsely compliant. For the tenant it is the live read of how exposed their fleet is to known-bad updates and the one place to scan, schedule and push fixes; with a tenant selected everything is scoped to that organization, with none selected it spans the whole fleet.

KPIs & compliance (click to filter): Nine cards across the top: Compliance %, Available, Critical, Security, Failed, Reboot required, Non-compliant, Offline and Unknown. Critical, Failed, Reboot, Non-compliant and Unknown turn warning-coloured when non-zero. Click any card to filter the device table to just those machines (the card outlines to show it is active); arriving from a Dashboard patch card pre-selects the matching filter.
Automated patch deployment banner: A banner reads "scheduled" (green) or "not configured" (amber) with a note — it answers "why was this not patched automatically?" and points you at Auto-Patch Policy to set the per-tenant rules.
Patches by operating system: A per-OS strip (Windows / Linux / macOS …) where each chip shows device count, available count, and crit / sec / upgrade / reboot pills plus a compliance %. Click a platform to highlight it and show only its patches in both the critical list and the device table; click it again, or "All platforms", to clear. "Upgrade" counts big feature/version jumps, not routine patches.
Severity & Compliance panels: Severity lists each class (critical, high, …) with its patch count and affected-device count. The Compliance bar splits the fleet into compliant / at risk / non-compliant / offline / unknown, and the legend defines them: Compliant = up to date, At risk = security updates pending with no critical, Non-compliant = critical or failed updates, Unknown = never scanned.
Compliance by tenant: When the view spans more than one tenant, a table breaks compliance %, critical, security, non-compliant and reboot counts down per tenant so you can see which organization is furthest behind.
Critical patches requiring action: One row per patch with its affected-device count, known-exploited (KEV) first so the most dangerous are at the top. "Compliance report" opens a printable per-fleet compliance summary.
Recent deployments: Visible with patch.deploy or patch.global_view: scoped patch rollouts (from "New deployment"), each row clickable for per-machine status.
Devices needing attention: Worst-first table: device, tenant, OS, compliance pill with its reason, available / critical / security / failed counts, a reboot pill (click to reboot the machine now when you have command.execute), the live apply status, and last-scan age. Honours the KPI and OS filters above.
Scan fleet: With patch.scan, queues a read-only patch scan on every online endpoint; the dashboard populates as agents report. Nothing is changed on the endpoints.
New deployment: With patch.deploy, roll patches out to a device, group, site, tenant or dynamic query — with a preview of who is targeted and an optional schedule — rather than applying to everything at once.
Apply patches: With command.execute, downloads and installs available updates on online endpoints using each one’s native updater — Windows Update on Windows; apt/dnf/zypper/pacman/apk on Linux. If an OS family is highlighted it applies to just that platform. It runs in the background and progress (applying → completed, with a reboot flag when pending) shows per device in the Apply column. Applying changes endpoints, so by policy it may require a second approver (administrators and engineers are exempt).

Patching

Lists and applies OS and third-party updates through each endpoint’s own update tooling, both as a fleet job across a group/tag selection and per-endpoint. SentinelOps has it so you can report and remediate updates centrally without logging into each machine, while keeping a human approval on anything that actually changes a box. For the tenant it is the hands-on patching console — read-only reporting is free, applying is approval-gated so an update is never pushed to their servers unreviewed.

Fleet patch — selectors: Target a selection, not everything: Device group (a dropdown of the groups in use, or "Any group") and Tags (comma-separated, all must match). A live counter shows how many endpoints match before you queue anything.
Fleet patch — operation: The Operation dropdown chooses List available updates (patch.list, read-only — no changes) or Apply updates (patch.apply). "Specific packages" (comma-separated, enabled only for Apply) limits the apply to named packages; leave it blank to apply all available updates. "Queue patch job" fans the job out to the matching endpoints — an Apply gets an approval-gated job per endpoint that a second operator must approve.
Per-endpoint actions: The Per-endpoint panel lists every enrolled machine with two buttons: "List updates" queues a read-only report (results appear on the device once the agent reports back), and "Apply…" prompts for optional package names and queues an approval-gated apply on just that machine.
Maintenance window: Devices outside their maintenance window are skipped automatically, and the toast tells you how many — so a server fleet can be gated to a window while workstations patch immediately.
Last rollout: After a fleet dispatch, a rollout panel lists each endpoint’s job and status; "Refresh status" re-polls the jobs so you can watch them move from awaiting-approval to succeeded/failed without leaving the page.

Software Library

Install common apps straight from a built-in catalog, or upload your own installer once and push either to a device, group or whole tenant with a button. SentinelOps has it so software roll-out is a central, repeatable, audited action instead of RDP-and-click on every machine. For the tenant it means apps arrive consistently and silently across their fleet; deploying changes endpoints, so it needs software.manage and may require a second approver by policy.

At a glance: The summary counts catalog apps, uploaded packages, how many packages are ready to deploy, and total deployments — so you can see what is available to push and what has been pushed.
Software catalog: A browsable, grouped-by-category list of common apps installable with no upload — driven by each machine’s own package manager (winget on Windows, the native package manager on any Linux distro, Homebrew on macOS). Incompatible machines are skipped automatically. "Install" on a card (or "Install from catalog") opens the deploy picker; "install any app by name" handles anything not listed.
Uploaded packages: "Upload installer" adds your own MSI / EXE / PKG / DEB / RPM / script, stored server-side and SHA-256 verified. Each row shows platform, size and status (ready / uploading % / failed, plus an "internal" badge for internally-owned packages). Deploy (enabled only when ready) pushes the file to each target and runs it silently, tolerating reboot-required exit codes; Edit changes its metadata; Delete removes it from the library (existing deployments are unaffected).
Scheduled deployments: Queue a rollout for later or on a cadence — Once, Hourly, Daily or Weekly — showing next run and enabled/paused state. Pause/Resume toggles it; Delete stops future runs (past deployments are unaffected). A schedule always fires for the package’s current version.
Recent deployments: Per-target status chips update automatically; click a row for the per-machine detail. The ✕ removes only the history record — it does not uninstall anything from any machine.
Deploy scope & approval: Deploying targets a device, a group or a tenant. Because it changes endpoints it requires software.manage and, by policy, may need a second approver before it runs.

Next: Lock machines down →