# job 01 · patching
Patching the operating system of a VPS you run
On a virtual server you run, patching the operating system falls to you. Where the server is supplied as Infrastructure-as-a-Service, ASD’s patching guidance says organisations “are still responsible for patching their applications and operating systems when using Infrastructure-as-a-Service”. For the operating systems of internet-facing servers, it recommends applying a patch within two weeks, or within 48 hours if the vendor identifies the vulnerability as critical or working exploits exist.
General information, not technical advice for your server. This guide rests on ASD’s Patching applications and operating systems (November 2023); the official place to check is cyber.gov.au.
why 48 hoursWhy the clock is short
ASD ties the deadline to exposure. Once a vendor releases a patch, “it should be applied in a timeframe commensurate with an organisation’s exposure to the vulnerability”. Its example explains the hurry: “once a vulnerability in an online service is made public, it can be expected that malicious code will be developed by malicious actors within 48 hours, sometimes within 24 hours.”
In this guidance a vulnerability means “a flaw in an application or operating system rather than a misconfiguration”, and what it says about patches applies equally to updates and other vendor mitigations.
timeframesASD’s timeframes for a server
ASD gives two lists, one for applying patches and one for scanning for missing ones, each “in prioritised order”. These are the rows a server operator meets first.
| What is patched | Apply patches | Scan for missing ones |
|---|---|---|
| “Online services” | “Within two weeks, or within 48 hours if identified as critical by vendors or working exploits exist.” | “At least daily.” |
| “Operating systems of internet-facing servers” | “Within two weeks, or within 48 hours if identified as critical by vendors or working exploits exist.” | “At least daily.” |
| “Operating systems of non-internet-facing servers” | “Within one month. However, for high-threat environments, within 48 hours if identified as critical by vendors or working exploits exist.” | “At least fortnightly.” |
When time and people are short, ASD’s order is the same: “patches should first be applied to internet-facing infrastructure.”
inventoryKnow what is installed, and whether the patch took
- “Establish a process to identify, assess and apply security patches as soon as possible.”
- “Prioritise patching vulnerabilities that pose the greatest risk to systems and business operations.”
- “Keep an inventory of applications and operating systems to help identify missing updates.”
- “Regularly check that patches have been successfully applied.”
The last of those does more work than it seems. ASD describes a common blind spot: not knowing the real patch status of your systems, and so believing a patch went on when it failed, or is still waiting for a reboot. Vulnerability scanners can gather that information. Where a scanner can’t be used, ASD points to the vendor’s own documentation on checking patch levels, and to manual audits.
faultsWhen a patch might break something
ASD takes the worry seriously. Patches can break applications or operating systems, and while many vendors test thoroughly before release, that testing is not always perfect. Its advice is to plan for faults with clear patch management processes and procedures.
Larger organisations
Might test every patch first, in a testing or staging environment.
Smaller organisations
Might go without the testing and set up a way to roll back instead. Modern software environments and deployment approaches make rolling back to a known good state easier.
Either way, ASD weighs the two risks in one sentence: “the immediate protection afforded by patching a vulnerability that is currently being exploited by malicious actors far outweighs the impact of the unlikely occurrence of having to roll back a patch.”
edge casesFreezes, bundled features, and no patch at all
During a change freeze
A quiet period for changes is not a quiet period for attackers. ASD says vulnerabilities should still be addressed during change freezes, “especially within 48 hours for internet-facing infrastructure”.
When security and features come together
Some vendors don’t offer security-only patches. A business using their products has to allow for that in its patching process, ASD says, because it “may need to be ready to implement feature changes at short notice” when a vulnerability is being exploited.
When there is no patch yet
“Temporary workarounds may provide the only effective protection if there are no patches available from vendors for vulnerabilities.” ASD’s examples are switching off the feature that has the flaw, or using firewalls or other controls to limit or block access to the affected service.
end of supportWhen the operating system stops getting patches
An operating system past its support date gets no more fixes, and the ISM, September 2026, is direct about it: “Operating systems that are no longer supported by vendors are replaced.” Vendors generally announce the end of support for operating systems well in advance, it notes, which leaves time to plan. Where removal or replacement can’t happen straight away, compensating security controls should be put in place until it can.
The small business handbook says the same in fewer words: “Remove or replace device and software that no longer receives security updates.”