Installed is not done. Done is restarted and healthy.
One deployment policy per client decides how updates arrive, when devices restart and what users are told. Every install is followed through the restart and checked on the way back up, and every reason something did not happen is on screen. Windows and Linux.
- Delivery
- Approved updates install inside the client's maintenance window, in batches sized to fit the time it has left.
- Reboot
- A user may postpone a restart four times. After 72 hours the device restarts anyway, with a 30-minute final countdown, and never between 22:00 and 07:00 device time.
- Preflight
- Nothing installs when disk space or power is short, on a metered connection, while someone presents, with another restart pending, or in the first 10 minutes after boot.
- Notification
- Users hear about it 15 minutes before the first batch, and the restart prompt carries the client's own branding.
- Clock from detection
- 24 hours
- Restart
- Forced
- Postponements
- One, of 15 minutes
- Outside the window
- Only if you allow it
Most patching stops one step short.
An update installs, Windows asks for a restart, and the device sits half-patched until somebody happens to reboot it. Patch compliance then looks better than it is by exactly as long as users go without restarting. Secuno treats the restart, and the health check after it, as part of the deployment.
Fewer half-patched devices
A device that needs a restart gets a restart plan with a real deadline. The fix no longer waits weeks for someone to reboot, and a device that did not come back is a finding, not a mystery.
No surprised users
Users see one sentence, the real deadline and how many postponements they have left, branded as their own IT provider. Quiet hours hold every restart, so nobody loses a machine late at night.
Every decision on the record
Each patch carries a decision log built from what actually happened to it: approval, lane, holds, restarts and postponements. When a client asks why a machine was not patched, the answer is already written down.
One policy per client, readable as four sentences.
Delivery, reboot, preflight and notification. Each clause is shown as a sentence built from its own values, so an account manager can read a client's policy back to the client without translating settings.
- Defaults that work on day one: workstations may postpone a restart four times, restart by a 72-hour deadline with a 30-minute final countdown, and keep quiet hours from 22:00 to 07:00 in their own local time
- Servers never restart on their own unless you decide otherwise
- A device group can carry its own policy, which wins for its members, so the finance team and the warehouse do not have to share one
- Policy templates let you set a standard once and bind it to every client that should follow it
- Maintenance windows govern Windows updates and third-party software alike, decide whether a restart is allowed at all, and can be evaluated in each device's own time zone
Five ways to restart, from never to forced.
Every device that needs a restart gets one plan in one of five modes. Updates that arrive while a plan is open join it, so a device restarts once per set of installs instead of once per update.
A prompt that tells the truth
One sentence, the real deadline and the real number of postponements left, in the client's branding. The choices are set by the platform, and every postponement is spent from the budget and recorded.
A countdown that cannot be clicked away
The final countdown is the operating system's own dialog, which cannot be dismissed. It is not a surprise, because the prompt has been showing the deadline all along.
Quiet hours hold every mode
Quiet hours and a closed maintenance window hold every restart mode. A deadline that expires at 23:00 waits for the morning.
Restart now, with five minutes' warning
An operator can restart a device on the spot. The user gets a fixed five-minute warning, and that restart is never held.
Nobody logged on, or a locked screen
With nobody logged on, a deferrable restart happens straight away, because there is nobody to disturb. A locked session waits until it is unlocked.
Every pending restart on one screen
Devices listed by deadline, with past-deadline and did-not-return devices flagged. Restart now, extend with a reason, or cancel, and a postponement report shows who keeps pushing back.
Did it come back healthy?
A restart is not the end of the deployment. The agent reports back every time it starts, and that report carries evidence of how the machine came up.
A device that does not return is a finding
If a workstation has not reported back 15 minutes after a restart, or a server 30 minutes, a high-severity finding says so. You hear about the machine stuck on a boot screen before its user calls.
Healthy means evidence, not a heartbeat
Services that were running before and are down now, a bugcheck, a boot loop or a spike in application crashes fail the plan. Each raises a high-severity finding that says what to do, and counts against the rollout ring the device is in.
No evidence is not good news
A return that arrives without a health snapshot is recorded as unmeasured. It is never counted as healthy.
Urgency set by exploitation, not by a severity label.
Every patch sits in one of four lanes, and each lane starts a clock at detection. The lane also shortens the approval wait and the ring soak, without changing the rules for what counts as a successful rollout.
Seen exploited here
A responder can record that a CVE was exploited at this client. Every update that fixes it moves to Emergency for that client, audited, and moves back when the observation is resolved.
Recalculated when the facts change
Lanes are recalculated at approval, the moment a CVE is added to the KEV catalogue, and every night. A new KEV entry also checks affected clients at once instead of waiting for the next sweep.
An emergency override you switch on
Emergency installs restart forced, with one 15-minute postponement. Letting them run outside the maintenance window takes a per-client override that is off by default and audited.
When an install is held, you can see why.
Six checks run before every batch. If one fails, the work goes back to the queue with its attempt refunded, and the reason is on screen rather than buried in a log.
- A reading the platform cannot take never holds an install, so a missing measurement cannot stall a client's patching
- A hold older than 72 hours becomes a high-severity risk, so a stuck device surfaces on its own
- One page lists every reason an install is not happening, and each device has its own deployment view
Batches sized to the window
Each update's install time is estimated from the fleet's median over its last 50 installs, or 8 minutes with no history. Updates are packed until the window's remaining time, less the restart allowance, is used. What does not fit waits for the next window without spending an attempt.
Content before the window
Updates can be downloaded ahead of time without installing, using Windows Update's own downloader or the Linux package manager's download-only mode. Staged content goes first in the next batch, and Delivery Optimization's download mode and bandwidth cap follow the policy.
Retries with a limit
A failing install is tried three times, not forever. Waiting for a user to sign in is counted separately from a real failure, and a broken update service is reported as exactly that instead of as every update in the batch failing.
Approval arms a patch. The window decides when it lands.
Approval and timing are separate decisions on purpose. A patch can be approved automatically after a waiting period you set per client and per severity, then moves through rollout rings that have to earn the next stage.
Let the vendor find the bad update first
Set a waiting period of 72 hours or more before auto-approval, and an update the vendor pulls in its first three days never reaches your clients.
Rings that treat silence as a warning
Each ring's verdict counts eligible, reported and succeeded devices separately, so nothing coming back is never mistaken for everything working. A ring that fails during its soak stops at once, a ring that goes quiet counts as a regression, and a halted ring rolls back in one click.
Roll back to a named version, and stay there
A third-party package can be rolled back to a specific earlier version and pinned, so the next automatic update does not walk the downgrade forward again.
Windows rollback, honestly scoped
Windows Update rollback covers only the updates Windows itself allows to be removed. The agent reports which those are, rather than the product promising a rollback it cannot perform.
Block one device, keep the approval
A single device can be excluded from a patch without withdrawing approval for the rest of the estate. That per-device veto is what makes ring rollouts workable in practice.
A broken scan changes nothing
Windows Update never says an update is superseded; it just stops offering it. Secuno retires one only after a scan that succeeded, ran online and was complete, because a broken update agent looks exactly like a fully patched device.
Built for the machines that are hardest to patch.
The servers you cannot restart at will, the workstations locked down with application control, and the Linux hosts where an upgrade restarts services.
Servers restart in order
A restart group restarts a set number of servers at a time, in the order you choose, with a health check between each. An optional backup gate waits for a recent backup time that your team records. Secuno does not take or verify backups.
Patching that application control allows
Windows updates are installed by talking to the Windows Update Agent directly, not by launching PowerShell, which is exactly what WDAC, AppLocker and Constrained Language Mode exist to block. Update titles never appear in a process command line.
Per-user apps, patched for the user
Third-party software is scanned as the system and as each signed-in user, then installed in the right context. A per-user app is updated in every active session, remote desktop hosts included, instead of a second copy landing under a service account while the vulnerable one stays put.
Third-party software through winget
Updates to third-party applications run through the Windows Package Manager, under the same approvals and maintenance windows, in the same list as Windows updates.
Linux: reported by default, installed when you say so
The Linux agent reports pending apt and dnf updates from the host's existing package data without refreshing it, so it never takes the administrator's lock. Installing is switched on per client by policy and is off by default, because a package upgrade restarts services.
Linux restarts, the Linux way
Linux desktops get a restart prompt and Linux servers a wall message, under the same deployment policy as everything else.
Every update, and every decision about it, in one place.
Windows updates and third-party software share one Updates list, with the lane, the deployment track and a default view of what needs you.
- A decision log per patch, read straight from what the deployment recorded rather than a summary written afterwards
- Windows updates carry the CVEs they fix, taken from Microsoft's own security update feed, so a pending update and the vulnerability it closes are one conversation
- From a vulnerability risk, Remediate approves the fixing upgrade for one device only while the package stays pending for the rest of the client. The approval clears after a successful install, so today's fix never pre-approves next month's release
- Patch reports run on a schedule you set, so a client hears how patching went without anyone assembling it by hand
- Approving and scheduling a patch are automation actions, so a rule can move routine work without a person clicking each one
The things worth asking first.
Will users be forced to restart in the middle of a meeting?
Not by default. Workstations get a deferrable restart: four postponements, a 72-hour deadline and a 30-minute final countdown, with quiet hours from 22:00 to 07:00. Someone presenting or in fullscreen holds the install before it even starts. The only forced restarts are Emergency-lane installs, which still offer one 15-minute postponement, and a Restart now that an operator chooses to send, which gives five minutes' warning.
What happens to servers?
Servers never restart on their own by default. Updates install and wait, and the restart happens when you run it or through a restart group, which restarts a set number of servers at a time, in order, with a health check between each and an optional backup-freshness gate. If a server has not reported back 30 minutes after a restart, a high-severity finding is raised.
Does it work where PowerShell is locked down?
Yes. Windows updates are installed through the Windows Update Agent directly, so WDAC, AppLocker and Constrained Language Mode do not block patching. A transitional PowerShell fallback still exists while the fleet moves over. It is logged every time it runs and goes once nothing needs it.
Can we roll back?
For third-party software, yes: roll back to a named earlier version and pin it, so the next update does not undo it. A halted rollout ring rolls back in one click. For Windows updates, only what Windows itself allows to be removed, and the agent reports which updates those are. A rolled-back patch cannot be queued again until someone reverses the rollback.
What about Linux?
Linux agents report pending apt and dnf updates without refreshing package metadata, so they never take the administrator's lock. Installing is off by default because an upgrade restarts services; you switch it on per client by policy. Updates can be downloaded ahead of the window, desktops get a restart prompt and servers a wall message.
How is an actively exploited vulnerability handled?
When a CVE is added to CISA's Known Exploited Vulnerabilities catalogue, the updates that fix it move to the Emergency lane with a 24-hour clock from detection. Recording that it was exploited at a client does the same for that client. Emergency installs restart forced with one 15-minute postponement, and with the per-client emergency override switched on they can run outside the maintenance window.
Finish every deployment. Surprise nobody.
Tell us how your clients patch today, and we will show you the same estate with a deployment policy, a restart plan and a decision log behind it.