Vulnerability scanning tools for Essential Eight patching what cadences need

Which vulnerability scanning tools meet Essential Eight patching cadences?

Any scanner that runs the required cadences against a complete asset inventory, with an up-to-date vulnerability database, can support the patch applications and patch operating systems strategies. No single tool is mandated. When a customer, contract or assessor asks for Essential Eight evidence, the question is rarely which product to buy. It is whether your scanning produces a defensible record that each asset class was discovered and checked at the frequency the maturity model requires. The Essential Eight is a set of mitigations rather than a certification scheme, so there is no ASD certificate to point to. The evidence is the scan configuration, schedules, coverage reports and remediation records.

Your organization owns the cadences, the asset scope and the remediation decisions. An implementation partner can configure discovery and scanning, set up schedules, build the evidence exports and document how the tool was tested for coverage. Only the independent assessor judges maturity. Before choosing a tool, confirm its handling of each asset class against the controls that set the cadences: discovery at least fortnightly (ISM-1807), daily scans for online services and internet-facing operating systems (ISM-1698, ISM-1701), weekly scans for office suites, browsers, email clients, PDF applications and security products (ISM-1699), and fortnightly scans for workstations and non-internet-facing systems (ISM-1702). At ML3, drivers and firmware also need fortnightly checks (ISM-1703, ISM-1900).

Coverage gaps matter more than feature lists. Open-source options differ in how they reach applications and operating systems. Greenbone Community Edition runs tests from its community feed, but the free feed excludes tests for enterprise products, so confirm that your estate's products are covered or budget for the paid feed. Wazuh and Fleet match installed software inventory against vulnerability sources, which means their results depend on agent enrollment and inventory accuracy. Microsoft Defender Vulnerability Management covers devices onboarded to Defender for Endpoint, so unenrolled devices fall outside the record. Test each tool against a sample of known assets and keep that test as evidence.

What must be scanned at each cadence

The ML1 patching requirements sort assets into cadence tiers by exposure and by how quickly they change. Each tier below sets a minimum scan frequency, and together they show that discovery must run before any scanning can be trusted.

Asset discovery every fortnight

Before scanning can cover anything, an automated discovery method must find the assets in scope at least fortnightly (ISM-1807). Discovery feeds the scanner's target list, so an unknown server or laptop is simply never scanned. The scanner itself must use an up-to-date vulnerability database (ISM-1808). Check that discovery covers cloud accounts, virtual machines and network devices, not only the domain-joined estate, and that a stale feed is flagged as a failure.

Daily scans for exposed systems

Online services must be checked for missing patches at least daily (ISM-1698). Operating systems of internet-facing servers and internet-facing network devices also need a daily scan (ISM-1701). These are the assets an attacker can reach without credentials, so a missed day is a real exposure window. Confirm the scanner can authenticate to these hosts, since unauthenticated scans often miss missing patches inside the operating system.

Weekly scans for common applications

Office productivity suites, web browsers and their extensions, email clients, PDF applications and security products must be checked for missing patches at least weekly (ISM-1699). These applications change often and carry much of the user-facing attack surface. Build an inventory of extensions and plug-ins as well as parent applications, because an outdated browser extension is a common gap in scan results.

Fortnightly scans for internal assets

Workstations, non-internet-facing servers and non-internet-facing network devices must be scanned for missing patches at least fortnightly (ISM-1702). This is the lowest cadence in the ML1 set, but it still applies to the largest share of endpoints. Check that laptops that are often offline or off the corporate network are still reached, either through an agent that reports back or through scheduled scans that retry.

Drivers and firmware at ML3

At Maturity Level 3, a vulnerability scanner must also check drivers and firmware for missing patches at least fortnightly (ISM-1703, ISM-1900). Most open-source scanners report operating system and application packages well but cover firmware and driver updates less reliably, so this tier often needs a vendor tool or a separate firmware inventory. Ask any tool vendor which driver and firmware sources it reads, and test it against a device with a known missing update before relying on it.

How open-source and Microsoft scanners cover each layer

Greenbone Community Edition runs the OpenVAS scan engine, which executes vulnerability tests from the Greenbone Community Feed against target systems. The feed is updated daily, and gvmd controls the scanner over the Open Scanner Protocol. The project is licensed under AGPL-3.0-or-later, so the reader should review the license terms with counsel before modifying or distributing the software.

Daily feed updates: The Community Feed is refreshed daily, which supports the daily scanning expectation for internet-facing operating systems and online services when scans are scheduled accordingly.
Enterprise product gap: The free feed excludes vulnerability tests for enterprise products, which are only in the paid Greenbone Enterprise Feed. Confirm whether your enterprise applications appear in the Community Feed before relying on it for those products.
Scan engine scope: The scanner tests network-reachable targets, so authenticated checks on endpoints depend on credentials and configuration you set up.
Licensing: AGPL-3.0-or-later applies to the components, which affects how you may modify and redistribute them.

Confirm with Greenbone which tests exist for your drivers, firmware and third-party applications, because the Community Feed coverage does not map one to one to your asset inventory.

What makes scanning more or less effort

The cadence is fixed by the Essential Eight maturity model, so the effort comes from how much the scanner has to cover and how well the results are sorted. The cards below cover the inputs that expand or shrink the work, and the controls that keep each one manageable.

Asset count and inventory accuracy

Discovery must run at least fortnightly to find assets for later scanning (ISM-1807), so every asset the discovery method misses is an asset that is never scanned. The effort rises with the number of endpoints, servers, network devices and cloud instances, and with the number of places they are registered. Check whether discovery draws from one source of truth or from several inventories that disagree, and reconcile them before counting scope. Confirm which assets the scanner reports as unscanned.

Internet-facing services and operating systems

Internet-facing online services and internet-facing operating systems of servers and network devices must be scanned daily (ISM-1698, ISM-1701), which is the most frequent cadence in the model. Each additional exposed service adds scan runs, faster result review and quicker patch decisions. Classify exposure explicitly in the asset inventory, because an asset that is reachable through a NAT rule or a forgotten load balancer is often misclassified as internal. Ask who approves a change to that classification.

Enterprise products that need a paid feed

The free Greenbone Community Feed excludes vulnerability tests for enterprise products, which appear only in the paid Greenbone Enterprise Feed. If your estate runs enterprise server software or vendor products in that category, a community-only scanner leaves gaps that an assessor will find. Map your installed enterprise products against the feed coverage before choosing a tool, and budget for the paid feed or a second source where needed. Confirm the feed terms with Greenbone directly.

Offline and air-gapped networks

Scanners that query a vendor cloud for vulnerability data cannot run as designed on isolated networks. A locally hosted copy of the vulnerability database must be kept current, which means a transfer process, a named owner and a record of the update date. Wazuh can use a locally hosted offline copy of its vulnerability repository, and Greenbone feeds are synchronized to the scanner. Plan the transfer path through your change process, and test that a scan on an isolated segment uses the current data.

Findings that need patch or exception triage

A scan produces findings, not patch decisions. Each finding must be matched to an owner, a patch or a documented exception, and a decision date, and the volume of findings grows with the number of software packages and the number of scan runs. Duplicate findings from overlapping scanners, and findings for software that is no longer in use, inflate the queue. Set rules for suppression and false positives, require a reason for each exception, and check that exceptions are reviewed on a schedule the organization sets.

How to set up scanning for an assessment

This sequence turns the scanning cadences in the Essential Eight into a documented, repeatable scanning program that an assessor can trace from asset to scan result to remediation. Each phase produces an artifact the next phase depends on.

Confirm the asset inventory and exposure
The organization's IT and security teams, with the implementation partner if one is engaged, compile the list of in-scope assets: online services, internet-facing servers and network devices, workstations, non-internet-facing servers and network devices, and drivers and firmware where ML3 applies. Each asset is classified as internet-facing or not, and each is assigned to an owner. The step is complete when the inventory lists every asset class with a classification and an owner, and the team can explain how the list was produced. Ask the scanning tool vendor or your asset discovery process to confirm it runs at least fortnightly, because the requirement is for discovery, not a one-time list.
Select scanners and confirm database currency
Select one or more scanners that cover the software categories in scope: operating systems, applications, drivers and firmware. Open-source options such as Greenbone Community Edition, Wazuh and Fleet can be self-hosted, while Microsoft Defender Vulnerability Management applies to devices onboarded to Defender for Endpoint. Confirm the license and feature limits of each, including whether the feed covers enterprise products, since the free Greenbone Community Feed excludes some enterprise tests. Record how each scanner updates its vulnerability data and how that update is checked. The output is a scanner register that names the tool, its scope, its data source and the person who verifies database currency.
Configure scan schedules for each cadence
Build one schedule per cadence in the Essential Eight requirements: daily scans for online services and internet-facing operating systems and network devices, weekly scans for office productivity suites, browsers and extensions, email clients, PDF applications and security products, and fortnightly scans for workstations, non-internet-facing servers and non-internet-facing network devices. Add fortnightly driver and firmware scans if the target is ML3. Each schedule should reference the asset group from the inventory, not an ad hoc list. The step is complete when a screenshot or export of each schedule matches the cadence table, and an assessor could trace each asset class to the schedule that covers it.
Run baseline scans and reconcile gaps
Run a full baseline scan across every asset group before relying on the scheduled jobs. Compare the scanned asset list against the inventory from the first step. Assets that were not scanned, scans that failed, and assets found on the network but absent from the inventory each become a gap record with an owner. Investigate unexpected findings to separate true missing patches from false positives, and note the scanner version and database date on each result. The step is complete when every inventory item is either scanned or has an open gap record, and the baseline report is saved with its date.
Route findings into remediation tracking
Send each confirmed finding to the patching owner with a severity, an asset reference and a target date set under the organization's own patch policy. The Essential Eight patch deadlines are defined in the maturity model, so confirm those deadlines against the current publication before writing them into the policy. Where a patch cannot be applied, record a documented exception with compensating controls and an approver. Link tickets to the scan result that raised them so the chain from detection to closure is visible. The step is complete when each open finding has an owner, a ticket and a recorded status.
Verify remediation with rescans
After a patch is applied, rerun the scanner against the affected asset and confirm that the finding no longer appears. Verification scans are kept separate from scheduled scans so the schedule history stays clean. If the finding persists, reopen the ticket and record the reason, such as a failed install or a package version that the scanner still flags. The step is complete when each closed ticket has a matching clean rescan, or a documented reason why it remains open.
Assemble scanning evidence for the assessor
Collect the evidence an independent assessor will ask for: the asset inventory and its discovery records, the scanner register with database update records, the schedule configuration for each cadence, baseline and recurring scan reports, gap and exception records, remediation tickets and verification rescans. Store these in a location with access control and retention set under the organization's records policy. Ask the assessor which format they prefer before collecting. The output is an evidence index that maps each Essential Eight scanning requirement to the documents that show it operating over time.

What must be in place before an assessment reviews scanning

An assessor testing scanning does not start with the tool. They start with whether the scanning program is documented, scheduled, current and acted on. The five items below connect the asset inventory to the scanner schedules, database currency, exceptions and remediation deadlines that the assessment will sample.

A documented asset discovery method

Scanning only covers assets the scanner knows about, so the discovery method has to be written down before anything else. Record the discovery tool, its scope (address ranges, cloud accounts, endpoints enrolled in management), and the schedule, which must run at least fortnightly under ISM-1807. Check that the output feeds the scanner's target list and that the reader can reproduce one discovery run from the document alone.

Scanner schedules matched to each asset class

Each asset class has its own cadence, and an assessor will compare the scanner configuration against the schedule in the policy. Online services and internet-facing operating systems need daily scans, common user applications need weekly scans, and workstations need fortnightly scans. Export the scan schedules and confirm that every asset group is assigned to the correct task, with no group left on a default schedule.

Evidence the vulnerability database is current

A scanner with an old feed will report a clean result against vulnerabilities it cannot recognize. Keep logs showing the feed update time for each scanning engine and check that the update ran on the schedule the vendor documents. Where the scanner runs offline or in an air-gapped network, record how the feed is transferred and when the last transfer happened. Confirm the feed edition, because some vendors restrict enterprise product tests to paid feeds.

A register of scan exceptions with approvals

Some assets cannot be scanned, such as fragile operational technology or systems behind restrictive segmentation. Each exception needs a written reason, a named risk owner, an approval date, a compensating control and a review date. Assessors sample this register and then check whether the excluded asset appears anywhere in the scanning evidence. Blank approvals and exceptions with no expiry are the most common gaps.

Proof that findings met patch deadlines

Scanning only matters if findings lead to patches within the deadlines set by the maturity level. Track each finding from detection to closure in a ticketing or patch management record, and keep the timestamps. Sample a set of findings from the scan reports and trace each to its closure or approved exception. Reports that show many open findings with no tickets, or tickets closed without a rescan, will not satisfy the reviewer.

Who owns scanning, who configures it, and who assesses it

The organization owns the Essential Eight scanning program. It decides which assets are in scope, sets the scanning cadence each asset class must meet, and accepts or rejects the risk of any finding that is not patched within the required window. No implementation partner can make those decisions on its behalf, and an assessor will ask who made them and when.

Cadence ownership: Set and document the daily, weekly and fortnightly scan frequencies for each asset class, and confirm that the scanners actually run on those schedules.
Asset inventory: Own the authoritative list of assets, including internet-facing services, and review the output of automated discovery at least fortnightly.
Remediation and patch decisions: Assign owners for each finding, track patch deadlines, and document exceptions.
Risk acceptance: Record who approves any accepted risk, the reason, and the review date, with signatures or tickets that an assessor can follow.
Operational records: Keep scan logs, exception registers and evidence of remediation over time, not only at the moment of assessment.

Confirm with your own assessor which records they expect to see for the past period, because the evidence must show the program running, not only configured.

What delays scanning projects and how to avoid it

Most delays in Essential Eight scanning projects come from gaps that surface only at assessment time: systems nobody inventoried, tools that cannot see enterprise products, and schedules nobody wrote down. Each card names one such gap and the step that closes it before the assessor arrives.

Incomplete asset inventories hide exposure

A scanner can only check what it knows exists. Internet-facing systems often arrive through cloud accounts, DNS records, vendor-managed appliances or old project environments that were never added to the asset register. The ISM requires an automated asset discovery method to run at least fortnightly (ISM-1807), so discovery must be scheduled, not run once during a project. Avoid this by reconciling discovery output against cloud accounts, DNS zones and firewall rules each cycle, and recording any unmatched asset as a finding.

Community feeds miss enterprise products

The free Greenbone Community Feed excludes vulnerability tests for enterprise products, which appear only in the paid Greenbone Enterprise Feed. A project that scans with the community feed alone can report a clean result for enterprise software that is actually unpatched. Before committing to a tool, list the enterprise products in scope and confirm in writing which feed covers each one. Where the paid feed is needed, include its licensing in the budget from the start.

Assuming Defender covers every device

Microsoft maps the internet-facing operating system, driver and firmware scanning requirements (ISM-1701, ISM-1703, ISM-1900) to Microsoft Defender Vulnerability Management, but only on devices onboarded to Defender for Endpoint. Servers, network devices and unmanaged endpoints outside that onboarding can fall outside the scan entirely. Avoid this by exporting the onboarded device list and comparing it with the asset inventory, then deciding how each gap will be scanned. Confirm licensing for each device class with Microsoft and your reseller.

Missing evidence of scan schedules

An assessor tests whether scanning happens at the required frequency, which requires proof, not intent. Scheduler configurations, job histories and report archives that were never retained leave a gap even when scans ran correctly. Daily scans of online services (ISM-1698), weekly scans of common applications (ISM-1699) and fortnightly workstation scans (ISM-1702) each need a dated record. Retain scan job logs, scanner feed update timestamps and exported reports in a location the scanning team cannot alter, and test that retrieval before the assessment window opens.

Stale vulnerability databases

The ISM requires a scanner with an up-to-date vulnerability database (ISM-1808). A scanner whose feed stopped updating after deployment will produce results that look normal but miss recent advisories. Self-hosted feeds need a sync path that works in the organization's network, and air-gapped environments need an offline update process. Monitor feed update timestamps as a scheduled check, and alert the owner when a feed is older than the agreed interval.

Questions buyers ask about Essential Eight scanning

Do we need one tool to scan for Essential Eight patching?

No. The Essential Eight does not name a product. It asks for two things: an automated asset discovery method that runs at least fortnightly, and a vulnerability scanner with an up-to-date vulnerability database. One tool can cover both, but many organizations split the work, for example a network scanner for servers and network devices and an endpoint tool for workstations. The practical question is whether your chosen tooling can show, for every in-scope asset, when it was discovered, when it was last scanned and what it found. Confirm that the output can be exported and retained as assessment evidence before you commit to a tool set.

Are open-source scanners enough for Essential Eight at ML1?

They can be, provided they meet the same functional requirements as any other scanner. The control asks for coverage, cadence and a current vulnerability database, not a commercial brand. Greenbone Community Edition (OpenVAS) is licensed under AGPL-3.0-or-later and runs tests from the daily updated Greenbone Community Feed. Its limit is that the free feed excludes vulnerability tests for enterprise products, which are only in the paid Greenbone Enterprise Feed. If your estate runs enterprise software, check whether the community feed covers those products or whether you need the paid feed. Wazuh (GPL-2.0-only) and Fleet (MIT) add host-level software inventory and vulnerability matching, which can complement a network scanner.

What vulnerability scanning cadences apply at ML1?

At ML1, automated asset discovery must run at least fortnightly. Vulnerability scanning must run daily for online services and internet-facing operating systems, and weekly for office productivity suites, web browsers and their extensions, email clients, PDF applications and security products. Fortnightly scanning applies to workstation operating systems. Internet-facing servers and internet-facing network devices are scanned daily, while workstations, non-internet-facing servers and non-internet-facing network devices are scanned fortnightly. Build a schedule from these categories first, then assign each asset to a category. Misclassifying an internet-facing system as internal is one of the most common ways to fail the cadence without noticing.

Does Microsoft Defender Vulnerability Management cover drivers and firmware?

Microsoft maps the daily and fortnightly vulnerability scanning requirements for internet-facing operating systems, drivers and firmware to Microsoft Defender Vulnerability Management, but only on devices onboarded to Defender for Endpoint. The drivers and firmware requirement is ML3 (ISM-1703, ISM-1900), which asks for fortnightly checks. Coverage depends on what the agent can inventory on each device, so test it on representative hardware before relying on it. Ask Microsoft and your own tenant administrators to confirm which driver and firmware data your licensing and device types expose. Where Defender does not cover a device class, you will need another method and documented evidence of it.

What does the work need from our own staff?

Your staff must own decisions that a scanner cannot make. They need to define the asset inventory boundary, classify assets as internet-facing or not, approve which tools are authoritative, and decide how findings move into patch deadlines. Someone must also review scanner configuration, confirm the vulnerability database is updating, and keep records of exceptions. Expect these tasks to recur on a schedule, not only at setup. Operations teams also need to be able to act on results, because a scan that finds missing patches creates no compliance value until the patch is applied or a risk decision is recorded.

Can an implementation partner run the scanning for us?

An implementation partner can plan, deploy, configure and document a scanning stack in your own infrastructure, then hand it over with runbooks and evidence procedures. DeployOpen works this way for self-hosted open-source platforms, typically under a fixed scope agreed in writing before work starts. Ongoing scanning operations, feed management and upgrades can be covered by a retainer. The organization still owns its controls and its patch decisions, and an independent assessor issues any assessment conclusion. Ask any provider to state in writing which tasks they perform, which remain with your team, and how evidence will be delivered to your assessor. DeployOpen does not publish a price list, so request a quote built from that scope.

How DeployOpen configures scanning and prepares evidence

DeployOpen plans, implements and documents vulnerability scanning inside your own infrastructure, mapped to the daily, weekly and fortnightly cadences your target maturity level requires. We prepare the scanners, asset discovery, scan records and evidence packs, while your organization owns the patching decisions and the independent assessor issues any conclusion about your maturity.

How we scope

Written scope lists every asset class to be scanned: online services, internet-facing and internal operating systems, workstations, drivers and firmware.
Scope records the target Essential Eight maturity level and the scan cadence each asset class must meet at that level.
Engagements are fixed-scope, with deliverables and timelines agreed in writing before any scanner is deployed.

How we build

Deploy the chosen open-source scanner inside your network, such as Greenbone Community Edition, Wazuh or Fleet, on infrastructure you control.
Configure asset discovery to run at least fortnightly and feed results into scan schedules matching each cadence.
Test scan coverage against a sample of known assets, and confirm the vulnerability feed updates on a schedule you can show an assessor.

How we hand over

Document scanner configuration, schedules, feed update settings, credentialed scan accounts and exclusions for your records.
Export scan reports and asset inventories in a format your assessor can sample, with dates and asset identifiers preserved.
Provide a gap list showing which asset classes lack a scanner, so your team can decide on remediation or a commercial feed.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after handover.
Retainer work can cover scanner updates, schedule reviews and refreshed evidence ahead of each assessment window.
Ask us to confirm in writing which parts of the scanner stack remain your responsibility after the engagement ends.