Open-source tools for the Essential Eight and their limits

Wazuh is licensed under GPL-2.0-only. For Essential Eight work it supports two strategies: patch applications and patch operating systems, through its vulnerability detection capability, and central logging for Maturity Level 2. Its agent collects a software inventory from each monitored endpoint, and the Wazuh server correlates that inventory with the Wazuh CTI vulnerability repository, or with a locally hosted offline copy, to identify vulnerabilities in the operating system and installed applications.

• Vulnerability evidence: Scan results list the affected endpoint, package and identified vulnerability, which gives an assessor a record to compare against patch deadlines.
• Offline operation: A locally hosted copy of the vulnerability data allows detection on networks that cannot reach the vendor repository, which matters for air-gapped environments.
• Log collection: Agents forward system and application logs to the server, which can also receive syslog and API feeds.
• Log analysis: Logs pass through pre-decoding, decoding and rule matching stages, so alerting and retention can be documented against ML2 event requirements.

Confirm which operating systems and applications your agents inventory, how often the inventory refreshes, and whether your ML2 log retention and tamper protection meet your target level.

Greenbone Community Edition is built on the OpenVAS scanner and is licensed under AGPL-3.0-or-later for the scanning components covered by the license terms in the gvmd repository. It supports the patch applications and patch operating systems strategies by running vulnerability tests against target systems on a schedule. The scan engine executes tests from the daily updated Greenbone Community Feed, and gvmd controls the scanner over the Open Scanner Protocol.

• Scan engine: The OpenVAS Scanner runs as a full-featured engine, so network and host scans can be scheduled and repeated.
• Feed updates: The Community Feed is updated daily, which supports a documented feed update routine.
• Enterprise coverage gap: The free feed excludes vulnerability tests for enterprise products, which only the paid Greenbone Enterprise Feed contains.
• Operator burden: Scan scheduling, credentials, target lists and report retention are handled by your team, not by the vendor.

Before relying on this tool, list the enterprise products in your estate, then confirm with Greenbone whether the Community Feed tests them. Where it does not, plan for another scanner or the Enterprise Feed, and document the gap.

Keycloak is licensed under Apache-2.0. It supports the multi-factor authentication strategy by providing two-factor authentication with passkeys, recovery codes, and TOTP or HOTP codes from apps such as Google Authenticator or FreeOTP. Its one-time password policies and W3C WebAuthn settings can be configured, which lets you set the methods your staff and customers use for sign-in to online services.

• Passkeys and WebAuthn: Phishing-resistant methods are available through passkeys and WebAuthn settings, which the Essential Eight expects at higher maturity levels.
• Recovery codes: Recovery codes provide a documented fallback, which assessors will ask you to control and monitor.
• OTP policy: TOTP and HOTP algorithm, digit and period settings are configurable, so the policy can be written down and evidenced.
• Scope limit: Keycloak protects applications that federate with it. Whether it covers your administrative sign-in, server access and other systems in scope is a question to confirm.

Map every system in the MFA scope against a Keycloak client or an alternative identity provider before you claim coverage. Confirm which methods your ML target accepts, since TOTP alone is not phishing-resistant.

Bareos is licensed under AGPL-3.0-only. It supports the regular backups strategy by performing backups, managing volumes and recording the catalog of jobs and files. Its job, file and volume retention periods control how long records stay in the catalog and how long a volume is guaranteed not to be reused. Those settings are the main way to show that backups cannot be overwritten or deleted during the retention window.

• Retention controls: Volume retention defines the period in which a volume is not reused, which is the basis for showing protection from deletion.
• Catalog records: Job and file retention determine how long restore points remain findable, which supports test restores.
• Volume management: Volume handling documents where backups are written and when they can be recycled.
• Immutability limit: Retention settings do not alone make backups immutable to a backup administrator. Confirm how your storage layer enforces write-once protection and who holds the credentials.

Review the Bareos volume management documentation with your backup design. Confirm how your storage target enforces retention independently of the Bareos administrator, because an assessor will test that point at ML3.

restic is licensed under BSD-2-Clause. It supports the regular backups strategy, specifically the integrity and test-restore expectations. Its check command verifies the structural consistency of snapshots, trees and pack files. When run with the read-data or read-data-subset options, it reads pack files back from the repository to confirm that the stored backup data has not been modified.

• Structural checks: The default check confirms that snapshots, trees and pack files are consistent, which is a fast routine to schedule.
• Data verification: The read-data options read pack files back, so the stored data is tested, not only the index.
• Scheduling and logs: Check runs can be scheduled and their output retained as evidence of integrity testing.
• Restore testing limit: A successful check does not prove that a full restore works. Test restores on a defined schedule and record the results separately.

Decide how often a full read-data check is practical for your data volume, then confirm the results are kept with the backup logs an assessor will request.

CISO Assistant is licensed under AGPL-3.0-only. It supports GRC tracking for the Essential Eight by running audits and compliance assessments against frameworks, with automatic mapping between them. It ships more than 200 frameworks, including ISO 27001, NIST CSF, SOC 2, PCI DSS, NIS2, DORA and GDPR. Whether the Essential Eight and the ASD ISM Essential Eight profiles are loaded in your instance is a question to confirm before you rely on them.

• Assessment tracking: The tool records assessments, findings and evidence against framework requirements, which gives you one place to track progress.
• Framework coverage: Confirm the Essential Eight and ML1 to ML3 profile content is present in the version you run, rather than assuming it.
• Automatic mapping: Mappings between frameworks are provided by the tool, so verify each mapping against the source framework before an assessor reviews it.
• Self-hosting: The tool runs in your infrastructure, so evidence and assessment records stay under your control.

Load the framework libraries in a test instance, confirm which Essential Eight and ISM profile content appears, and check each mapping against ASD's published profiles before relying on the output.

The organization owns the Essential Eight implementation in full. Its people decide which mitigation strategies apply, how far each one is pursued toward a target maturity level, which tools are used, who can access them, how long records are kept and when a control is considered met. These decisions stay internal even when a partner does the installation work, because they define the organization's risk position and carry its accountability.

• Scope and target level: Choosing the target maturity level for each strategy and approving the systems in scope.
• Tool selection and licensing: Deciding which open-source or commercial components to run and confirming their license and edition limits.
• Access and retention rules: Setting who may view logs, administer scanners and delete or alter backups, and how long each record is kept.
• Operating routines: Running scans, reviewing alerts, performing restore tests and recording the results on a schedule.
• Sign-off: Approving evidence packs and accepting residual risk before anything goes to an assessor.

Before engaging anyone, confirm internally who holds each of these decisions and who has authority to accept a gap.

An implementation partner such as DeployOpen works inside the client's own infrastructure, whether that is its cloud accounts, data centers or air-gapped networks. The partner plans the deployment, installs and hardens the tools, configures them to the agreed scope and documents how each one produces evidence. Its output is a working, documented system and a set of evidence artifacts that the organization reviews and approves. The partner does not decide maturity and does not issue assessment reports.

• Planning and architecture: Mapping each tool to the strategies and levels in scope, sizing the deployment and agreeing the design in writing.
• Installation and hardening: Deploying the tools, applying secure configuration and restricting administrative access to them.
• Configuration and integration: Connecting agents, feeds, log sources and backup targets so that the required data is collected.
• Documentation and evidence preparation: Writing runbooks, configuration records and sample outputs that show how each control operates.
• Ongoing support: Upgrades, testing and operational support, often under a retainer, if the organization buys it.

Typically, the partner's scope is fixed and written down before work starts, so check that the statement of work names every deliverable and states who receives it.

The independent assessor reviews the evidence and reaches the assessment outcome. Depending on the engagement, this may be an external assessor or auditor who is independent of both the organization and the partner. The assessor tests whether each strategy is implemented and whether it is effective against the maturity model, then reports its conclusions. Because the Essential Eight is a set of mitigations rather than a certification scheme, there is no ASD certificate; the assessor's report is the basis for any maturity statement the organization makes.

• Evidence review: Sampling configurations, logs, scan results, backup records and restore test outcomes against the requirements.
• Effectiveness testing: Checking that controls work in practice, not only that they are configured.
• Independence: Keeping separate from the team that built the tooling, so the outcome is not influenced by the implementation.
• Outcome and reporting: Issuing the assessment conclusion for each strategy and level in the assessor's own report.
• Follow-up: Recording findings the organization must address before a later assessment.

Ask any assessor how it will handle the partner's documentation and confirm in writing that it will not accept the partner's summaries as its own conclusions.