What Essential Eight patch operating systems ML1 requires
At Maturity Level One, the Essential Eight patch operating systems strategy asks for three things: scan operating systems for missing patches on a fixed cadence, apply those patches within deadlines set by internet exposure and severity, and replace any operating system the vendor no longer supports. The ML1 baseline expresses these as ISM-1701 and ISM-1702 (scanning), ISM-1877 and ISM-1694 (patch deadlines for internet-facing servers and network devices), ISM-1695 (one-month deadlines for workstations and internal systems), and ISM-1501 (replacing unsupported systems). ISM-1807 and ISM-1808 underpin all of it by requiring asset discovery and an up-to-date vulnerability scanner at least fortnightly. The risk is well understood: flaws in operating systems are routinely exploited soon after vendors publish fixes, so an unpatched host is often the easiest way in. The difficulty is almost never the patch itself. It is knowing which hosts exist, and deciding which of them are internet-facing.
Those two problems drive most of the work. Asset inventories are often incomplete, especially for cloud instances, branch equipment and devices that were added outside the change process, and a host missing from the inventory will never appear in a scan. Exposure classification is also contested. Teams disagree about whether a server behind a load balancer, a VPN concentrator or a DMZ host counts as internet-facing, and the answer decides whether the deadline is 48 hours or one month. Before assessment, document a written exposure rule, apply it to every asset, and record who approved it. Confirm with your assessor how they expect the internet-facing boundary to be drawn, and confirm the exact deadline wording against the current ISM profile rather than relying on secondhand summaries.
Start with the inventory. Export the list of operating systems in use, mark the vendor support end date for each, and flag anything that needs replacing under ISM-1501. Then run a scan on the required cadence and compare the results against the inventory to find hosts that the scanner never reached. Open-source options such as Wazuh, Fleet, GLPI and Zabbix can help with discovery and software inventory, but each has different coverage, so confirm which operating systems and package sources each one supports in your environment before you rely on it for evidence. Keep the scan output, patch records and exception approvals together, because an assessor will ask you to show that the cadence and deadlines were met over time, not just on the day of review.
Which systems and teams fall inside the ML1 patch scope
The ML1 operating system patching controls set different scan cadences and deadlines depending on how exposed a system is. Scope starts with classifying each system into one of four groups, then settling the decisions that decide which group a system lands in.
Internet-facing servers
Servers reachable from the internet are scanned for missing operating system patches at least daily under ISM-1701. Patches must be applied within 48 hours when the vendor rates them critical or they are known to be exploited, and within two weeks otherwise. Check every public address, load balancer, reverse proxy and NAT rule, since a server behind a forwarded port is internet-facing even if its own network looks private.
Internet-facing network devices
Firewalls, routers, VPN concentrators and load balancers that accept traffic from the internet fall under the same daily scanning and 48 hour or two week deadlines as internet-facing servers. Vendors often ship these devices with their own operating system images, so confirm that the firmware or network operating system is included in your scanner's inventory, not only general-purpose servers.
Workstations and internal systems
Workstations, non-internet-facing servers and non-internet-facing network devices are scanned at least fortnightly under ISM-1702 and patched within one month of release at ML1. Laptops that roam between offices, home networks and public Wi-Fi need a clear rule for when they count as internal, because they may spend time outside your perimeter between scans.
Classifying internet-facing systems
Write a rule that the asset owner and security team both sign, rather than relying on hostname conventions. Record the source of truth for each classification, such as firewall rules, DNS records or cloud security groups, and re-check it when network changes occur. Assessors will ask how a system's group is decided and how that decision is kept current.
Cloud and SaaS-hosted operating systems
Virtual machines you run in a cloud account are your operating systems and count in full, including their scanning and deadlines. Managed platform services and SaaS products where the provider patches the operating system are a different case, and the assessment depends on contract terms and the evidence the provider supplies. Ask the provider in writing which operating system versions it patches and how it reports patch status to you.
End-of-support decisions and owners
Operating systems the vendor no longer supports must be replaced under ISM-1501, so the decision needs a named owner, usually the platform or infrastructure lead with sign-off from the system owner. Keep a register of end-of-support dates for each operating system version and record exceptions with a risk owner and a replacement date. Confirm the vendor's support dates directly, since they change.
How to implement ML1 operating system patching in sequence
The sequence turns operating system patching from an ad hoc habit into a documented cycle: every system is known, scanned at the required cadence, held to exposure-based deadlines, and retired when the vendor stops supporting it. Each step produces an artifact an assessor can sample.
Build a complete asset inventory
Start by listing every server, workstation and network device in scope, including cloud instances and devices that connect only occasionally. Record the operating system and version, the owner, the location and whether each system is internet-facing, since that flag decides the scan cadence and patch deadline. Your CMDB or inventory tool should hold this record. Done means you can export a single inventory extract that reconciles against your cloud accounts and network records, with no unexplained gaps.
Classify systems by exposure
Split the inventory into internet-facing servers, internet-facing network devices, and everything else, which covers workstations, non-internet-facing servers and non-internet-facing network devices. The classification drives both the scanning cadence and the patch deadline, so the rules must be written down, not left to individual judgment. Done means each asset carries an exposure tag and the tagging rule is recorded in your patching standard.
Deploy and verify the vulnerability scanner
Deploy a vulnerability scanner that can read operating system patch levels and keep its vulnerability data current. Open-source options such as Wazuh, Fleet and Zabbix-based inventory can supply the software inventory, but you must confirm that each one covers your operating systems and that its vulnerability data updates on a schedule you can evidence. Your team owns the configuration and the decision to use a given tool. Done means a test scan of a known host reports its missing patches correctly and the data source timestamp is visible.
Run scans at the required cadence
Schedule daily scans for internet-facing servers and network devices, and fortnightly scans for workstations and internal systems. Also run asset discovery at least fortnightly so newly connected systems enter the inventory. Keep the scan schedule, job logs and reports for each run. Done means an assessor can pick any date in the review period and find the scan that covered each in-scope system, with the cadence visibly met.
Set a patch deadline matrix
Translate exposure and vendor severity into a deadline matrix. Internet-facing servers and network devices must be patched within 48 hours when the vendor rates the patch critical or the vulnerability is being exploited, and within two weeks otherwise. Workstations, non-internet-facing servers and non-internet-facing network devices must be patched within one month of release. Have the security owner approve the matrix and the clock start point. Done means a signed matrix that maps each exposure and severity combination to one deadline.
Build the patch pipeline and exception process
Establish how patches move from release to deployment: testing, change approval, deployment rings, and verification by a follow-up scan. Define an exception process for systems that cannot meet a deadline, requiring a named owner, a documented reason, a compensating control and an approval date. Done means a sample patch ticket traces from scan finding to verified closure, and every exception has an approval and an expiry.
Retire unsupported operating systems on a dated plan
Identify every operating system the vendor no longer supports and assign each one a replacement or decommissioning date, with an owner and budget line. Track them in a retirement register that the scan results feed. Until a system is replaced, record its exception and compensating controls. Done means the register lists every unsupported system with a date, and the count of unsupported systems trends toward zero in each scan report.
Keep evidence ready for assessment
Gather the inventory extract, scan schedules and reports, the deadline matrix, patch tickets, exception approvals and the retirement register into one evidence folder with a review date. Confirm the ISM controls that apply to ML1 with your assessor before the review, since the mapping determines which evidence they test. Done means a reviewer can follow one system from inventory to scan to patch to closure using only the folder contents.
How an assessor tests the ML1 patch cadence and deadlines
The assessor first asks whether vulnerability scanning of operating systems runs at the cadence the ML1 controls set: at least daily for internet-facing servers and network devices, and at least fortnightly for workstations, internal servers and internal network devices. The assessor picks a sample of systems from the asset inventory and then requests scan logs or scanner reports for each one, checking that the timestamps fall inside the required interval across the assessment period, not just on the day of review.
- Coverage gaps: Systems present in the inventory but absent from scan scope are the most common finding. Ask whether the sample includes cloud instances, virtual machines and devices added since the last scope review.
- Missed runs: A scanner that failed silently for several days breaks the daily requirement even when it ran correctly the rest of the month.
- Classification errors: An internal server exposed through a forwarded port may be internet-facing in practice, which moves it to the daily cadence.
- Asset discovery: The controls also expect asset discovery at least fortnightly with an up-to-date scanner. Evidence should show when discovery last ran.
- Unsupported scanner definitions: Stale vulnerability data can make a scan technically run but unable to detect current issues.
Before the assessment, confirm that scan scope matches the current inventory and that the scan history for each sampled system is retrievable without manual reconstruction.
The second check compares the date a patch was released against the date it was applied. The ML1 deadlines differ by exposure and severity: 48 hours for vendor-critical or exploited patches on internet-facing servers and network devices, two weeks for other patches on those systems, and one month for workstations, internal servers and internal network devices. The assessor samples vulnerabilities from scanner output and traces each one to a change record or patch deployment log, then checks whether the dates fall inside the applicable deadline.
- Wrong clock: Assessors usually count from the vendor release date or the date the vulnerability was flagged, depending on how the control is read. Confirm the start point with your assessor before the test.
- Exceptions without approval: Deferred patches with no documented risk acceptance, owner sign-off or compensating control are a frequent finding.
- Severity misclassification: A patch rated high by the scanner but marked critical or exploited by the vendor can fall under the 48-hour deadline.
- Evidence mismatch: A scanner showing a finding as open does not prove the patch was never applied, so the assessor may ask for deployment records from the patch tool.
- Reboot gaps: A patch installed but not activated because the system was not restarted may not count as applied.
Keep a dated exception register and link each sampled finding to its deployment record.
The third check looks at whether each sampled operating system still receives security updates from its vendor. The ML1 requirement is that unsupported operating systems are replaced, so an assessor checks the vendor's published support status for every version in the sample, not only the versions the organization expects to be in use. Support end dates are set by the vendor and can change, so the check should use the date of assessment.
- Legacy machines: Old workstations, appliances and embedded systems are often missed because they sit outside the standard build process.
- Mixed versions in one fleet: A fleet with several operating system versions needs each version checked, not a single sample representative.
- Extended support contracts: Where a vendor offers paid extended support, assessors will ask for the contract and confirm that the coverage is current.
- Replacement plans: For systems that cannot yet be replaced, the assessor will look for a dated plan, owner and interim controls.
- Asset records: The inventory must show operating system version for each asset, or the sample cannot be checked.
Before the assessment, reconcile the inventory's operating system field with what the scanner reports and record the vendor support status with its source and date.
Which evidence passes an ML1 operating system patch assessment
An assessor testing operating system patching at Maturity Level One looks for proof that scanning happened on time, that patches landed within the deadlines, and that exceptions and unsupported systems were handled on purpose. The cards below describe the artifacts that carry that proof and how to keep each one current between assessments.
Scanner configuration and schedule
Export the scanner's configuration, including the scan schedule, the asset groups it covers and the vulnerability feed it uses. The schedule must show daily scans for internet-facing servers and network devices and fortnightly scans for workstations and internal systems. Store a dated copy of the configuration each quarter, and record every change with a ticket reference so the assessor can see when the cadence was set and by whom.
Scan history showing cadence
The assessor will sample scan logs across the assessment period, so the history matters more than the configuration. Keep scan reports for the whole period, not only the most recent run. Gaps are the usual finding: a scanner that stopped for two weeks in one quarter fails the cadence even if the configuration is correct. Set an alert for missed scan runs so the gap is caught when it happens.
Asset inventory with exposure tags
A scan only covers what the organization knows about, so the asset inventory is the first thing an assessor checks. Each record should show the operating system, the owner and whether the system is internet-facing. The exposure tag decides which deadline applies, so a server tagged wrongly is assessed against the wrong timeline. Reconcile the inventory against discovery results at least fortnightly, which is the discovery cadence the control expects.
Patch deployment records
For each patch, keep a record linking the vendor release date, the severity rating, the affected systems and the date the patch was applied. The assessor measures the gap between release and deployment against the 48 hour, two week or one month deadline, so the record must show both dates. Records pulled from the patch management tool are stronger than manually written summaries. Export them monthly so the history survives tool changes.
Exception approvals
Some patches cannot be applied inside the deadline because of a dependency, a vendor compatibility issue or a change freeze. Each exception needs a written approval that names the system, the reason, the compensating measure and an expiry date approved by an accountable manager. Assessors check that exceptions are rare, time-limited and reviewed. An exception that never expires, or one approved after the deadline has passed, is a common finding.
End-of-support register
Maintain a register of operating systems that the vendor no longer supports, with the replacement plan, the target date and the named owner for each system. The control requires unsupported systems to be replaced, so the register is the evidence that the organization knows where it stands. Review the register at each patch cycle and remove entries only when the system is decommissioned or replaced. Keep the decommissioning records as proof that the replacement actually happened.
What meeting ML1 operating system patching costs
This table breaks down the cost components of meeting ML1 operating system patching, showing who is paid for each, whether it is one-time or recurring, and what drives it up or down. Use it to structure a quote request and to separate open-source licence savings from the labour that remains.
| Cost component | One-time or recurring | What drives it |
|---|---|---|
| Scanner tooling or licences | Licence fees recur; self-hosted open source removes licence spend but not hosting or setup | Number of endpoints and servers in scope, and whether the scanner needs a locally hosted offline vulnerability copy |
| Asset inventory build | One-time build, then recurring upkeep | Fleet size, how many systems are unmanaged or shadow IT, and whether the GLPI Agent or similar can push inventory automatically |
| Engineering time for the patch pipeline | One-time build, then recurring tuning | Number of operating system families, change windows, and how many systems need staged rollouts |
| Internet-facing system identification | One-time mapping, then recurring review | Count of internet-facing servers and network devices, since these carry the daily scan and 48-hour or two-week deadlines |
| Replacing unsupported operating systems | One-time project, often the largest single cost | Size of the legacy estate, application dependencies on old systems, and hardware refresh timing |
| Recurring evidence upkeep | Recurring | Scan records, patch deadline reports and exception approvals that an assessor will request for each cycle |
| Independent assessor time | Periodic, per assessment | Scope size, quality of evidence on arrival, and whether the organization has already reconciled its inventory |
| Organization staff time | Recurring | Owners who approve exceptions, run change windows and answer assessor questions |
Who owns, implements and audits ML1 patching
Your organization owns the patching control. That means the patch policy, the deadlines your teams commit to, the exception process and the decisions to retire an operating system. An implementation partner can draft these documents and set up the tooling that enforces them, but the accountable owner signs them, approves exceptions and decides when a system leaves service. Assessors will ask who made each decision and whether the record shows it.
- Patch policy: Written rules that map each system class (internet-facing servers, network devices, workstations, internal servers) to a scan frequency and a patch deadline.
- Exception approval: A named owner who accepts or rejects requests to miss a deadline, with an expiry date and a compensating measure.
- Retirement decisions: Authority to take unsupported operating systems out of service and set replacement dates.
- Ownership of the asset register: Accountability for keeping the list of systems accurate, including systems added by business units.
- Operational follow-through: Staff who apply patches, reboot systems and record completion.
Confirm with your assessor which records they will sample and who must be able to explain each exception.
An implementation partner typically builds the parts of the pipeline that your staff lack time or skills to assemble: the asset inventory, the vulnerability scanning schedule, the reporting that shows scan currency and patch age, and the documentation that explains how each output maps to an ISM control. DeployOpen works this way. It prepares systems and evidence inside your own infrastructure and hands over documented, working controls. It does not decide your deadlines and it does not certify your position.
- Inventory and discovery: Configuring asset discovery so scans cover every in-scope system at the required frequency.
- Scanner configuration: Setting up a vulnerability scanner, updating its data sources on schedule, and separating internet-facing from internal targets.
- Evidence pipeline: Exporting scan results, patch timestamps and exception logs in a form an assessor can sample.
- Runbooks and documentation: Written procedures that your staff can run after the engagement ends.
- Knowledge transfer: Training for the staff who will operate the tooling.
Agree in writing which systems, scanners and reports are in scope before work begins, and confirm who owns the configuration after handover.
The independent assessor tests whether the control works as described. For ML1 patching, that usually means selecting a sample of systems, checking scan records against the required frequency, comparing patch dates against the deadlines in your policy, and reviewing exceptions and retired systems. Only the assessor issues the conclusion. Neither your team nor an implementation partner can issue an assessment result, a report or a certificate.
- Sampling: Choosing systems from the asset register and from scanner output to test coverage.
- Timing tests: Comparing scan and patch timestamps with the ISM-linked deadlines.
- Exception review: Checking that each late patch has an approved, time-limited exception.
- Evidence sufficiency: Deciding whether the records are complete, consistent and traceable.
- Conclusion: Stating the result in the assessor's own report.
Ask the assessor which evidence they will accept, whether they require an independent review of your inventory, and how they will treat tooling output produced by a third party.
Outsourcing is common in the build phase and rare in the decision phase. Organizations often pay a partner for scanner setup, inventory integration, dashboards and documentation. They keep policy approval, exception authority, retirement decisions and day-to-day patch execution in house, and they pay an assessor for independent testing. Managed service providers may run the scanner on your behalf, but accountability for the outcome still sits with your organization.
- Usually outsourced: Initial tool deployment, scanner tuning, inventory integration and evidence export scripts.
- Usually retained: Policy approval, deadline setting, exception sign-off and retirement decisions.
- Recurring cost: Scanner licensing or hosting, feed updates and staff time for monthly review.
- One-time cost: Design, configuration and documentation.
- Quote question: Ask each provider which deliverables transfer to you and which remain under their control.
Check that the scope in any proposal lists each deliverable and names the party responsible for it.
Where ML1 operating system patching usually fails
Maturity Level One patching depends on knowing what runs, how exposed each system is, and whether the deadlines are proven in records. The gaps below are where organizations most often fall short when an assessor asks for evidence.
Incomplete asset inventory
Scanning only covers systems the team knows about. Shadow servers, branch devices, and workloads spun up outside the standard build process often sit outside the asset register. Asset discovery must run at least fortnightly, so compare discovery results against the register each cycle and record every unmatched host. Check whether cloud accounts and network devices feed the same inventory.
Exposure classification not kept current
Internet-facing status changes faster than the register. A test server opened for a vendor, a firewall rule added during an incident, or a forgotten public address can move a system into the daily scanning and 48 hour or two week tier. Review exposure classification at each scan cycle, and reconcile it with firewall and load balancer configuration rather than relying on the original design document.
Scanners not covering non-internet-facing systems
Internal workstations and servers are often scanned less often than required. Teams usually configure daily scans for the perimeter and forget the fortnightly cadence for workstations, internal servers, and internal network devices. Confirm each scan policy names its target group, and check that scanner credentials work on the internal population, since failed authenticated scans can look like clean results.
Deadlines met on paper only
Patch dates exist in tickets but not in system state. A change record can show a patch approved and closed while the host still reports the missing update. Compare the patch deployment date with the scanner's next clean result for each affected host, and keep both in the evidence pack. Assessors look for proof that the system changed, not proof that a ticket was closed.
Unsupported systems kept without a dated plan
End-of-support operating systems keep running with no retirement date. ML1 requires unsupported operating systems to be replaced, so a system past vendor support needs a documented replacement or isolation decision with an owner and a date. Track vendor end-of-support dates in the inventory and flag them early, so the replacement work starts before support lapses.
Questions buyers ask about ML1 operating system patching
How much effort does Essential Eight ML1 operating system patching take?
Most of the effort comes from keeping an accurate inventory and running scans on schedule, not from the patches themselves. ML1 asks for daily scanning of internet-facing servers and network devices, fortnightly scanning of everything else, and patch deadlines of 48 hours or two weeks for internet-facing systems and one month for workstations and internal systems. The effort rises with the number of device types, the number of unmanaged endpoints and how many change approvals each patch needs. Ask any partner to break its quote into asset discovery, scanner setup, patch workflow design, evidence collection and the first assessment cycle, so you can see which parts recur.
Can our own team implement ML1 operating system patching without outside help?
Yes, an internal team can meet ML1 if it has ownership of the asset inventory, a vulnerability scanner it can run on the required cadence, and a patch process that meets the deadlines. Teams often bring in outside help for the initial scanner deployment, integration with existing configuration management, and documentation that an assessor can follow. The organization always owns its controls and its evidence. An implementation partner can prepare systems and records, but only an independent assessor can test and report on them.
How long does it take to reach ML1 patching compliance?
The timeline depends on how complete your asset inventory is and how many systems fall outside existing patch tooling. A clean estate with working patch management can move quickly, while an estate with unknown internet-facing services or unsupported operating systems needs discovery and replacement work first. Replacing unsupported operating systems, required by ISM-1501, is often the longest task because it depends on application owners and change windows. Ask any partner for a fixed-scope plan with milestones, and confirm the assessment date with your independent assessor, since the assessor sets the evidence window.
What does the partner need from our organization to start?
The partner needs read access to your asset sources, network ranges and existing scanning or patch records, plus named owners for servers, network devices, workstations and applications. It also needs access to change approval processes, maintenance windows and any exceptions already granted. Without these, the partner cannot tell which systems are internet-facing or which operating systems the vendor no longer supports. Agree on the deployment location early, since self-hosted tools run inside your cloud accounts, data centers or air-gapped networks.
Do self-hosted open-source tools satisfy an assessor for ML1 patching?
Open-source tools can produce the evidence an assessor needs, but the tool does not satisfy the control by itself. An assessor looks for scan results on the required cadence, patch records showing deadlines were met, and a list of operating systems with their vendor support status. Wazuh vulnerability detection, Fleet vulnerable software detection, GLPI asset records and Zabbix host inventory can each help produce parts of that record. Confirm with your assessor which report formats and retention periods they accept before you design the evidence pack.
How do the ML1 operating system patching rules differ from ML2 and ML3?
The operating system patching controls at ML1 and ML2 are the same, so moving from ML1 to ML2 for this strategy mainly adds logging, log analysis and incident response requirements that sit elsewhere in the baseline. ML3 is stricter. It requires 48 hour deadlines for critical vulnerabilities on all systems, patching and scanning of drivers and firmware, and running a current or previous operating system release. Plan ML1 with the ML3 deadlines in mind if you expect to move up, because a patch process designed only around the one month workstation deadline will need rework.
What should we ask a partner about cost before signing?
Ask for a written scope that lists every system in the estate, the scanners and patch tools to be deployed, the number of operating system types covered and the evidence the engagement will hand over. Ask which costs are one-time, such as deployment and documentation, and which recur, such as scanner upkeep and patch cycle support. Ask who pays for replacing unsupported operating systems, since that work often falls outside a patching engagement. DeployOpen publishes no price list; a quote follows from the written scope.
How DeployOpen scopes and prepares ML1 patching evidence
DeployOpen plans, implements and documents self-hosted open-source platforms inside your own infrastructure, so the scanning and patch-tracking evidence for Patch operating systems at Maturity Level One is generated where your systems run. The organization keeps ownership of its controls, and an independent assessor reviews the evidence.
How we scope
- Written scope lists which internet-facing and internal servers, network devices and workstations fall under the ML1 patching controls.
- Scope records the scanning cadence and patch deadlines each asset class must meet, including the one-month and two-week windows.
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before any work starts.
How we build
- Deploy a vulnerability detection platform, such as Wazuh, Fleet or a similar option, against your asset classes after confirming its coverage.
- Configure asset discovery and inventory so fortnightly discovery runs and the software list stays current for each endpoint.
- Test that scans, deadline reports and unsupported-operating-system flags behave as documented before handover.
How we hand over
- Document scan schedules, deadline logic, exception handling and the owner for each asset class in a runbook.
- Provide evidence exports showing scan timestamps, patch dates and unsupported systems, formatted for the independent assessor.
- Train the responsible staff on reviewing reports and escalating overdue patches, and confirm the handover in writing.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- Retainers can cover scanner updates, vulnerability feed checks and periodic re-testing of the patching controls.
- Ask for the support scope, response arrangements and evidence refresh cadence in the written quote.
