Patch applications maturity level 1: requirements and evidence

What Essential Eight patch applications ML1 requires in practice

At Maturity Level One, the Essential Eight patch applications strategy asks your organization to know what software it runs, scan it on a fixed cadence, and patch within deadlines that depend on severity and exploit status. Discovery must run at least fortnightly, online services must be checked for missing patches daily, and common user applications must be checked weekly. Patches for online services are due within 48 hours when the vendor rates the flaw critical or a working exploit exists, and within two weeks otherwise. Patches for office suites, browsers and their extensions, email clients, PDF applications and security products are due within two weeks, and vendor-unsupported versions of these must be removed. The Australian Signals Directorate (ASD) publishes this as a set of mitigations rather than a certification scheme. No ASD certificate is issued, so your assessor will test whether each requirement is implemented and effective against the maturity model, using the control IDs in the ISM baseline profiles as a reference.

The risk is exploitation of known vulnerabilities in internet-facing and user-facing software, where attackers use a published flaw long before a patch reaches every machine. The hard part is usually not the patch itself but knowing what exists. Browser extensions installed by individual users, SaaS services bought by a single department, and remote endpoints that rarely join the network often fall outside the asset list. A scanner cannot test what discovery has missed, so the deadlines are measured against an inventory that is incomplete from the start. Ownership gaps make it worse: nobody is named to accept a SaaS service's patch status, and no one decides who removes an application when its vendor ends support.

Start by confirming three things before you buy or configure anything. First, decide who owns each class of asset, including SaaS tenants and browser extensions, and record that owner in your asset register. Second, set the scan schedule to match the daily and weekly cadences and keep the vulnerability database current. Third, agree who evidences each deadline, so that a patch date, a vendor mitigation or a removal decision can be shown to an assessor. Open-source options such as GLPI's Assets module can hold the inventory, while Wazuh and Greenbone are often paired with it for detection. Confirm each tool's coverage of your estate in a proof of concept, because platform inventory depth varies across operating systems and application types.

Which systems and applications fall under ML1 patch deadlines

Maturity Level One sets different patch deadlines for different kinds of software, so the first job is sorting every system into the right group. The cards below cover the four deadline groups, the unsupported software that must be removed, and the scoping decisions that change how much work each group creates.

Online services and critical deadlines

Online services are patched on the tightest ML1 timetable: within 48 hours of release when the vendor rates the vulnerability critical or a working exploit exists, and within two weeks otherwise. Vulnerability scanning must check these services for missing patches at least daily. Confirm which internet-facing services your organization runs, who owns each one, and whether the vendor publishes severity ratings you can track against the 48 hour clock.

Office suites, browsers and extensions

Office productivity suites, web browsers and their extensions, email clients, PDF applications and security products form the second group. Each must be patched within two weeks of release at ML1 and ML2, and scanned at least weekly. Extensions are easy to miss because they install outside the main application package, so include them in the inventory and confirm that browser extension updates are captured by your scanner.

Email clients, PDF tools and security products

This group includes the endpoint agents, antivirus and detection tools that run on your workstations and servers, as well as the mail clients and PDF readers staff use daily. Security products are often managed by a separate team or a vendor console, so the patch owner may not be the person who runs the scanner. Agree on one register that lists each product, its owner and its patch channel before the first scan.

Unsupported applications to remove

Online services, office suites, browsers and extensions, email clients, PDF applications, Adobe Flash Player and security products that vendors no longer support must be removed, not just left unpatched. Build a list of end-of-support dates from each vendor's lifecycle page, and treat any application without a supported release as a removal task with an owner and a due date. Flash Player is a common example of software that still turns up in older environments.

Vendor-managed SaaS and shared responsibility

Software-as-a-service products are patched by the vendor, which changes what your organization must prove. You still need evidence that the service is in scope, that it is covered by your scanning and that the vendor's patch timing meets the deadline. Ask each SaaS vendor for its patch and vulnerability disclosure commitments in writing, and record which deadlines the vendor meets and which remain your responsibility, such as browser-based access or connected plug-ins.

Shadow IT and unmanaged applications

Applications installed by staff, trial services signed up with work email and departmental tools bought outside procurement often escape the inventory. Asset discovery must run at least fortnightly to find these assets before scanning, so unmanaged software is the biggest source of gaps in an ML1 scope. Check discovery results against expense records, identity provider sign-ins and network traffic, and decide in advance whether unknown applications are blocked, approved or investigated.

How an assessor tests the ML1 patch cadence

This table sets out how an assessor typically tests each ML1 patch applications control, the evidence they request and the gaps they most often find. Read it as a checklist for your own pre-assessment: for each row, confirm that the schedule exists and that the records prove it ran on the required hosts and applications.

Control area	Test approach and evidence requested	Common findings
Asset discovery (ISM-1807, ISM-1808)	Assessor samples discovery jobs and checks run history for at least one fortnight, then compares discovered assets against a sample of network segments or cloud accounts. Evidence: job schedules, run logs, scanner version and feed update dates.	Discovery is configured but last ran weeks earlier, or scanner feed was not updated, so the asset list is stale.
Daily online service scanning (ISM-1698)	Assessor selects online services and checks that daily scan results exist for each sampled service across the assessment window. Evidence: scan reports dated per day, target lists and scan credentials status.	Gaps in daily results, or online services missing from the target list because they were added after the scan was configured.
Weekly user application scanning (ISM-1699)	Assessor samples workstations and servers, confirms that office suites, browsers and extensions, email clients, PDF applications and security products appear in weekly scan or inventory data. Evidence: weekly scan reports and application inventory exports.	Browser extensions and PDF tools not detected, so scanning covers the operating system but not the user applications the control names.
Patch deadlines for online services (ISM-1876, ISM-1690)	Assessor takes critical or exploited vulnerabilities from scan results and traces each to a patch or vendor mitigation applied within 48 hours, or within two weeks where the rating is lower. Evidence: vulnerability tickets, change records, vendor advisory dates.	Deadlines measured from ticket creation rather than vendor release, or mitigations recorded without a date.
Patch deadlines for user applications (ISM-1691)	Assessor samples recent vendor releases for office suites, browsers, email clients, PDF applications and security products, then checks the installed version on sampled hosts two weeks after release. Evidence: version inventory snapshots and deployment records.	Version drift on a minority of hosts, often laptops that were offline during the deployment window.
Unsupported application removal (ISM-1905, ISM-1704)	Assessor compares installed application inventory against vendor end-of-support dates for the named categories and checks whether removal or documented exception exists. Evidence: inventory exports, removal tickets, exception register.	End-of-support software still installed on a few hosts with no removal record or approved exception.
Sampling and the schedule-versus-execution gap	Assessors usually select a sample of hosts and applications across each in-scope group, then test the period in question rather than a single day. A schedule that exists in configuration is not enough: the assessor needs run records that cover every sampled period.	Scanner configured correctly but scans failed silently, credentials expired, or targets were excluded, so results do not cover the full population.

Sequence to implement ML1 patching and scanning

This sequence turns patching from a set of deadlines into a working cycle: a known asset list, a scanner that checks it on schedule, agreed application lists, two patch clocks, and a dated record that shows the cycle ran. Each step produces an artifact an assessor can inspect.

Establish the asset inventory
Start by deploying an asset discovery method that finds computers, servers, network equipment and other endpoints across the environment. Platform engineering or IT operations owns this work, with the security team reviewing coverage. GLPI can hold the asset register, populated manually or by the GLPI Agent, and Wazuh's Syscollector can add endpoint inventory. The step is complete when the inventory lists every in-scope asset, the discovery job is scheduled to run at least fortnightly, and each run's output is retained as evidence.
Select a scanner with a current vulnerability database
Choose a vulnerability scanner and confirm it pulls an up-to-date vulnerability database before it is trusted with the fortnightly asset list. Greenbone Community Edition (OpenVAS) draws its tests from the daily updated Greenbone Community Feed, and Fleet matches installed software against sources including the NVD and OSV. Security engineers should document which feeds are used, how updates are verified, and who approves the choice. The step is complete when a test scan returns results and the feed update history is logged.
Define the online service list
Work with application owners to list every online service the organization uses or exposes, including services it runs itself and those provided by vendors. The security lead signs off the list and the scanner targets are mapped to it. Ask each owner which vendor advisories they subscribe to, since that determines how quickly a critical patch or mitigation is noticed. The step is complete when the signed list matches the scanner's target configuration and every service has a named owner.
Define the user application list
Build the list of office productivity suites, web browsers and extensions, email clients, PDF applications and security products in use across endpoints. Endpoint management owns the list and confirms it against the inventory from the first step. Include browser extensions explicitly, because they are named in the requirements. The step is complete when the list is approved, each entry maps to at least one inventory record, and the weekly scan scope is configured to cover it.
Set the two patch clocks
Write the patch deadlines into a procedure the operations team can follow. Online service patches or vendor mitigations go out within 48 hours when the vendor rates the issue critical or a working exploit exists, and within two weeks otherwise. User application patches go out within two weeks of release. Name the approver for exceptions and the record that will capture any deviation. The step is complete when the procedure is approved, ticketing or patch tooling is configured to start both clocks from the vendor release date, and a test ticket shows the timer running.
Remove unsupported software
Compare the approved lists against vendor support status and identify any online service, office suite, browser, extension, email client, PDF application, Adobe Flash Player or security product that the vendor no longer supports. Remove each one or record a documented plan with a named owner and removal date. Confirm removals through the inventory so the asset register no longer shows the software. The step is complete when the unsupported list is empty or every item has an approved removal record.
Run the first full evidence cycle
Run one complete cycle from start to finish: discovery, daily and weekly scanning, patching against both clocks, and removal review. Collect the outputs as dated evidence, including inventory exports, scan reports, feed update logs, patch tickets and the unsupported software review. The security lead reviews the bundle against the ML1 requirements and records gaps. An independent assessor, not the implementation partner, decides whether the evidence meets the level. The step is complete when the evidence bundle is filed, gaps have owners, and the cycle repeats on schedule.

How the 48 hour and two week deadlines are calculated

The deadline clock starts at vendor release, the date the patch or vendor mitigation for an affected product becomes available, not the date your scanner reports it or a ticket is opened. Online services carry the shorter clock. A 48 hour deadline applies when the vendor rates the vulnerability critical or when a working exploit exists. Otherwise the deadline is two weeks. Both triggers depend on information you do not control, so record the vendor's severity rating, the advisory reference, the release timestamp and the source you used to confirm any exploit. If a working exploit appears after release, record the date you learned of it, and confirm with your assessor how that date affects the deadline you are measured against.

Vendor mitigations count toward the deadline, but only when they are the vendor's documented workaround, such as a configuration change or a disabled feature named in the advisory. Apply the mitigation inside the same window, record who applied it and when, and keep a open item to install the full patch later. A workaround you wrote yourself is a compensating measure, not a vendor mitigation, and should be handled under the exception process below. Office productivity suites, web browsers and their extensions, email clients, PDF applications and security products follow the two week clock regardless of severity rating, so your tracking should separate these categories from online services from the start.

When a patch cannot be applied within the deadline, record a documented exception before the deadline passes. The record should name the asset and application, the advisory reference, the reason the patch cannot be installed, the compensating control in place, the expiry date of the exception and a named business owner who accepts the residual risk. Security staff should not sign off alone. Exceptions do not reset the clock in the standard, so an assessor will test whether the exception existed, was approved in time and was reviewed. Confirm the exception wording and evidence expectations against the ISM controls in the ISM OSCAL catalog and with your assessor before you rely on them.

Evidence that satisfies the ML1 patch requirement

An assessor testing Patch applications at Maturity Level One looks for proof that discovery, scanning, patching and removal happened on schedule, not only that a policy exists. The cards below cover the records that show each cadence and deadline was met, and how to keep them current between assessments.

Scan schedules and run logs

Keep the schedule that sets the daily scan of online services and the weekly scan of office suites, browsers, email clients, PDF applications and security products. Retain the run logs that show each scan actually executed, with start time, target count and completion status. A schedule alone is weak evidence. Check for gaps across weekends and public holidays, since a missed weekly run is the most common failure an assessor finds in a log set.

Dated asset inventory exports

ISM-1807 requires an automated discovery method to run at least fortnightly, so the evidence is a series of dated inventory exports rather than a single snapshot. Each export should list hosts, installed applications and versions, and the discovery run that produced it. Store them in a read-only location with the export date in the file name. Confirm that the inventory covers endpoints, servers and cloud workloads, because an assessor will test whether a scanned asset can be traced back to a discovered one.

Scanner feed update records

ISM-1808 expects the vulnerability scanner to run against an up-to-date vulnerability database. Keep the feed update log, showing the date and version of each vulnerability data sync, next to the scan results it supported. A scan run against a feed that is weeks old produces results an assessor will discount. For self-hosted scanners, record the feed source and the sync job's success or failure, and alert on failed syncs so the gap is caught before the next assessment.

Patch deployment reports against release dates

For each patch, the assessor compares the vendor release date with the date the fix reached the asset. Online services need patches or mitigations within 48 hours when the vendor rates the issue critical or a working exploit exists, and within two weeks otherwise. Office suites, browsers, email clients, PDF applications and security products need patches within two weeks. Report each item as release date, deployment date, and days elapsed, so the deadline check can be repeated without reconstruction.

Exception register with approvals

Some patches cannot meet a deadline, for example when a vendor fix breaks a line-of-business application. Record each exception with the affected asset, the reason, the compensating mitigation, the named risk owner, the approval date and a review date. An undocumented miss looks like a control failure, while a documented, approved and time-limited exception shows the organization is managing the risk. Review open exceptions at each scan cycle and close them once the patch lands.

Unsupported software removal records

ISM-1905 and ISM-1704 require removal of online services, office suites, browsers, email clients, PDF applications, Adobe Flash Player and security products that vendors no longer support. Keep the list of unsupported products found in each inventory export, the removal ticket for each, and a post-removal inventory showing the product is gone. Confirm the vendor end-of-support dates from each vendor's own documentation, since those dates are the basis for the removal decision.

What meeting ML1 patching costs in money and effort

This table breaks down the cost components of meeting Patch applications at Maturity Level One, showing who is paid, whether each cost is one-time or recurring, and what moves it up or down. Use it to build a quote request and to separate tooling spend from the staff time and evidence work that usually costs more over the life of the control.

Cost component	Who is paid or who does the work	One-time or recurring, and what drives it
Scanner and inventory tooling	Vendor for commercial licenses, or internal staff and an implementation partner for open-source tools such as GLPI, Wazuh, Fleet or Greenbone Community Edition	Open-source licenses carry no fee, so cost is mainly setup and hosting. Commercial licenses recur, priced by asset or host count. Scope drives both.
Asset onboarding and discovery setup	Internal platform or IT engineers, or a partner under a fixed-scope agreement	One-time for initial enrollment of endpoints, servers and online services. Recurs as new assets appear. Clean CMDB data and agent deployment tooling keep it down.
Deadline tracking and patch workflow	Internal IT operations staff, sometimes supported by a retainer	Recurring. Driven by the number of online services, the volume of patches and how many deadlines (48 hours, two weeks) the team must track. Automated ticketing reduces it.
Scanner tuning and false positive review	Security engineers or a managed service provider	Recurring. Rises with estate complexity and with scan results that lack accurate asset context.
Evidence upkeep	Internal compliance or GRC staff, or a partner preparing evidence	Recurring. Requires exporting scan cadence records, patch dates and unsupported-software removal records for each review. Retained reports and consistent naming lower the effort.
External vulnerability testing or review	Independent security testing firm, under a written scope	Usually periodic rather than continuous. Cost depends on scope, number of applications and whether testing is a one-off or a retainer. Request a written scope and deliverables.
Assessor sampling effort	Internal staff supporting the assessor, and the independent assessor	Recurs with each assessment. Driven by how many patch cycles, scan reports and removal records the assessor samples. Organized evidence reduces staff hours.

Which self-hosted tools produce patch evidence

GLPI is an IT service management platform, and its Assets module is the system of record for the devices and software your organization owns. It can hold computers, monitors, software, network equipment, peripherals, printers, phones and racks, entered manually or pushed automatically by the GLPI Agent through native inventory built into GLPI since version 10. The inventory supports the fortnightly asset discovery expected at ML1, because the list of assets that scanners target must be complete and current.

Asset register: A dated list of computers and network devices that can be exported as proof of what was in scope during a given period.
Software records: Installed applications collected by the GLPI Agent, which show the versions your patch deadlines are measured against.
Agent-based collection: Automated pushes from endpoints, which reduce reliance on hand-maintained spreadsheets.
Licensing and ownership: GLPI is licensed under GPL-3.0-or-later, so the license terms should be reviewed by your legal team before deployment.

Confirm that the GLPI Agent reaches every device class in your estate, including devices outside the domain, and that the software list includes the office suites, browsers, PDF tools, email clients and security products named in the ML1 controls.

Where ML1 patching usually fails an assessment

Patch applications at Maturity Level One is mostly a matter of proof: an assessor needs to see that discovery, scanning and patch deadlines ran on schedule and were recorded. The gaps below are the ones that most often turn a working process into a finding, and each one has a closing action the organization can take before the assessment starts.

Inventory misses SaaS and browser extensions

Discovery tools built for servers and endpoints often skip cloud-hosted services and the browser extensions installed on user profiles. ISM-1807 expects an automated discovery method that runs at least fortnightly, so an inventory that lists laptops but not the online services or extensions in use leaves those assets unscanned for patches. Check whether the discovery output includes every online service and every browser extension in scope, and reconcile it against the list of approved SaaS subscriptions from procurement.

Scans run but produce no evidence

A scanner that runs on schedule is not enough if nobody keeps its output. Assessors look for scan records with dates, the scanned asset list, and a vulnerability database that was current when the scan ran, which ISM-1808 requires. Many teams find that scans were configured but their reports were overwritten or never exported. Set retention for scan results and confirm that the vulnerability feed update timestamp appears on every report.

Two week clock not tracked to release

The patch deadline for most applications runs from the vendor's release date, not from the date the team first saw the patch. ISM-1691 sets two weeks from release for office suites, browsers, email clients, PDF applications and security products at ML1. Without a record of release dates alongside the date each patch was applied, a team cannot show it met the deadline. Add release date and deployment date as fields in the vulnerability tracker and report any item past its window.

Unsupported apps kept without exceptions

Legacy line-of-business applications often stay in service because a vendor upgrade is costly or a integration depends on them. ISM-1905 and ISM-1704 require that online services, and the listed application categories, that vendors no longer support be removed. An assessor will accept a documented exception with an owner, a risk acceptance and a removal date, but will not accept an unsupported application that appears in the inventory with no record. Build an exception register that lists each unsupported application and its planned retirement.

Security products excluded from weekly scans

Endpoint protection agents, VPN clients and other security products are sometimes left out of application scanning because they are managed by a separate team. ISM-1699 requires a vulnerability scanner to check security products for missing patches at least weekly, alongside office suites, browsers, email clients and PDF applications. A gap here is easy to miss because security tooling rarely shows up in standard application reports. Confirm that the scanner's scope list includes security products and that their results reach the same tracker as other applications.

Questions buyers ask about Essential Eight patch applications ML1

How much effort does Essential Eight ML1 application patching take?

The effort depends mostly on how many applications are in scope, how many online services are publicly exposed, and how much of the estate already reports into a single inventory. ML1 asks for four things to run on a repeating cycle: asset discovery at least fortnightly, daily scanning of online services, weekly scanning of common user applications, and patching against the 48 hour and two week deadlines. Most of the recurring work is triage: reviewing scanner output, deciding which findings are real, testing patches, and recording exceptions. No public figure for hours is supplied here, so ask any provider to break its quote into discovery, scanner setup, patch workflow, evidence capture and ongoing review, and to state which of these recur each month.

Can our own team implement ML1 patching without outside help?

Often yes, if the team already runs endpoint management and has an owner for vulnerability findings. The harder parts are usually not the tools but the agreed processes: who owns each application, how a 48 hour deadline for an online service is triggered, and how an exception is approved and recorded. Teams with few security engineers often bring in a partner for the initial scanner and inventory build, then keep the cycle in-house. The organization always owns its controls and the decisions behind them, and an independent assessor, not any implementer, judges whether the evidence meets the maturity level.

What does the work need from our staff and systems?

It needs named owners and working access to the systems that the scanning and inventory tools must reach. In practice this covers:

Administrative access to endpoints and servers for inventory collection
Network paths from the scanner to online services and internal hosts
An application owner for each product, with authority to approve patch windows
A ticketing or change process that records dates, decisions and exceptions
Someone who reads scanner output each cycle and can explain why a finding was closed

Without these, the scanner may run on schedule but the evidence will not show that findings were acted on within the deadlines.

How long does preparation take before ML1 patching starts?

No preparation duration is supplied here, so treat any timeline with caution until it is tied to a written scope. The length depends on the number of asset sources, the state of existing inventory, how many applications have unclear owners, and whether network access for scanners needs approval. Ask for a plan that separates discovery and scanner deployment from process definition and evidence collection, and that names the dependencies each phase has on your own change approvals. Confirm the sequence with your own environment before committing to dates.

Is there an ASD certificate for Essential Eight ML1 patching?

No. The Essential Eight is a set of mitigation strategies, not a certification scheme, so ASD does not issue a certificate for patch applications or any other strategy. Maturity is shown by assessing how each strategy is implemented and whether it works against the maturity model. Implementation partners can prepare systems and evidence, but only an independent assessor can give an opinion on the maturity level. Ask any provider that offers a certificate to explain who issues it and under what authority.

How do the ML1 patch rules differ from ML2 and ML3?

ML1 sets the baseline: scanning of online services daily and common user applications weekly, 48 hour or two week deadlines for online services, and a two week deadline for common user applications. ML2 keeps those rules and adds fortnightly scanning and a one month deadline for all other applications, alongside log protection and incident reporting. ML3 tightens the rules for common user applications, requiring critical vulnerabilities to be patched within 48 hours and removal of every unsupported application, not only the common categories. Plan the ML1 inventory and workflow so they can scale to these stricter rules later, and confirm the exact requirements against the ISM Essential Eight profiles and the maturity model.

How DeployOpen scopes and prepares Essential Eight patch evidence

DeployOpen plans and implements self-hosted open-source tooling inside your own infrastructure so that application patch cadences at Maturity Level One can be measured and evidenced. We prepare systems, controls and evidence for your assessment, while your organization owns its controls and an independent assessor makes the judgment.

How we scope

Written scope lists the online services, office suites, browsers, email clients, PDF applications and security products in your estate
Scope records which asset discovery and vulnerability scanning cadences apply to each application category
Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts

How we build

Deploy asset discovery so inventory refreshes at least fortnightly, feeding the scanner with current hosts
Configure a vulnerability scanner with an up-to-date vulnerability database and daily checks for online services
Set weekly scanning for other in-scope applications and test that patch deadline tracking reflects the required timeframes

How we hand over

Documentation of tool configuration, scan schedules, asset coverage and patch deadline logic
Evidence packs with scan reports, inventory exports and records of unsupported application removal, organized by ISM control ID
Handover session so your staff can run the tooling and explain the evidence to your independent assessor

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after handover
Retainer work can keep feed updates, scan cadences and evidence collection running between assessment cycles
Confirm with us in writing which support duties sit with your team and which sit with DeployOpen before signing