The Essential Eight will not secure the software you ship

The Essential Eight contains no software development controls

Not few. None.

Every one of the 108 controls in the Information Security Manual's Guidelines for software development carries the tag Essential 8: N/A. The ISM's guidelines for database systems, and for procurement and outsourcing, carry the same tag throughout. ASD's own Essential Eight to ISM mapping contains no software development control at all.

The tag is not decorative. In the ISM's Guidelines for system management, 36 of 57 controls carry Essential Eight maturity tags. The field works. It is simply empty for software development.

The wider list of 37 strategies contains one development-adjacent item: "server application hardening, especially internet-accessible web applications (sanitise input and use TLS not SSL) and databases". It is rated Very Good, not Essential, and was not promoted into the eight.

So: the Essential Eight governs how an organisation runs its corporate IT. It has nothing to say about the software that organisation builds. Anyone offering Essential Eight maturity as evidence that their product is secure is answering a different question.

Where it does bind a software company

Four places, all specific.

1. If you host it, it is an "online service" in the harshest patching tier

ASD defines an online service as "any service that is directly accessible over the internet, including those sitting behind a perimeter firewall". Your SaaS product is one. So is the client application you host.

That puts you in the strictest tier of patch applications, at every maturity level including Level One:

• Vulnerability scanning daily
• Patch within 48 hours where a vulnerability is critical or a working exploit exists
• Patch within two weeks otherwise
• Remove online services the vendor no longer supports

There is no Level One discount here. The 48-hour clock starts on "the announcement of a working exploit or that exploitation is already occurring, whichever occurs first."

ASD's own suggested mitigation, for organisations that cannot move that fast, is to move to "mature and trustworthy cloud service providers" for the faster patching that follows.

2. The apps you build inherit customer MFA obligations

This is the one that lands in a backlog rather than a runbook.

If your client is bound by the Essential Eight and the application you are building is an "online customer service" handling sensitive customer data, then multi-factor authentication becomes a product requirement:

Phishing-resistant means smart cards, security keys, Windows Hello for Business or passkeys. Not SMS. Not voice calls. Not "remember this computer", which ASD rejects outright because the token verifies the browser rather than the user. Not security questions, which ASD does not recognise as a valid memorised secret.

If a client tells you at handover that they need Level Two, and the product only speaks SMS one-time passwords, that is a re-architecture, not a configuration change. It belongs in scoping.

3. The cloud carve-out that makes DevOps legal

Restrict administrative privileges requires that privileged accounts be prevented from accessing the internet, email and web services. Read literally, that would make cloud administration impossible.

It is not literal. The requirement excludes "those explicitly authorised to access online services". ASD's Assessment Process Guide confirms that "some privileged user accounts, such as those used to manage cloud services, may have access to the internet."

The obligation is that the authorisation is explicit and the access strictly limited to what is required. It does not require your engineers to administer AWS from an air-gapped room. This clause is misread often enough to derail otherwise sensible programmes.

4. It arrives through contracts, whether or not you are mandated

Most software companies are not directly bound by the Essential Eight. They meet it anyway, through procurement.

PSPF obligations require agencies to ensure their service providers, contractors and subcontractors comply with relevant requirements. That obligation is passed down the chain in contracts.

Two of those contracts are worth knowing by name. The BuyICT Digital Marketplace Panel agreement requires sellers to meet a stated Essential Eight Maturity Level and the ISM, and to provide "evidence of assessment, certification and compliance". Defence Industry Security Program members must meet the full Essential Eight at Maturity Level Two; assessments against the old "top four" ended on 15 November 2025. The DISP Cyber Security Questionnaire runs to 107 controls in its Essential Eight section alone.

ASD also tells organisations to demand it of their managed service providers: "Ensure your contract requires your MSP to maintain a good internal security culture, and to implement cyber security guidance such as the Essential Eight."

And there is a mirror to that, which ASD states plainly:

Likewise, an organisation will transfer any cyber supply chain risk they hold to their customers.

You are somebody's supply chain.

What actually governs the code you ship

If the Essential Eight is the wrong instrument, these are the right ones.

The ISM's Guidelines for software development

The 108 controls the Essential Eight does not cover. The ones a web or SaaS team should treat as a checklist:

The June 2026 ISM extends this chapter's scope to AI-assisted development: where it refers to software developers, "they apply to humans and AI."

Secure by Design

ASD's Secure by Design foundations define a "technology manufacturer" as "any organisation, team or individual who develops digital products and services". That is a custom software firm, and it is the category ASD is addressing.

Its six foundations run: a holistic secure organisation, early and sustained security, secure product development, testing, continuous assurance, and secure deprecation. Foundation three is explicit that supply chain protection now includes "AI-generated code, open-source code and all transitive dependencies".

The joint international guidance ASD co-sealed puts the argument more bluntly than ASD usually does: "The software industry needs more secure products, not more security products", and manufacturers who are secure by default "do not charge extra for implementing added security configurations. Instead, they include them in the base product like seatbelts are included in all new cars."

Choosing secure and verifiable technologies

Your prospects will use this document to evaluate you. It lists the questions buyers are told to ask their software suppliers:

• Is the manufacturer developing products following a secure-by-design methodology or framework?
• Is the manufacturer providing an attestation against an industry product development standard such as the ISM or SSDF?
• What percentage of the product has code written in a non-memory-safe language? Is there a memory-safe roadmap?
• Can the manufacturer provide evidence of the testing regimen (penetration testing, unit and integration coverage, field testing)?
• For SaaS solutions, can the data be accessed by a managed service provider or cloud service provider? If so, how is this controlled and audited?
• Have all open-source libraries been code reviewed, scanned and tested? Are they in a software bill of materials, including all inherited components?

If you cannot answer those, Essential Eight maturity will not cover the gap.

Why this matters commercially

ASD's Annual Cyber Threat Report 2024–2025 contains one statistic that makes the case better than any framework argument:

For business, "Exploit Public-Facing Application" accounted for 10% of incidents — against 2% for government entities.

Government fleets are the ones with mandated Essential Eight maturity. Businesses, which largely are not, get compromised through their applications five times as often.

The same report notes over 120 incidents involving attacks on edge devices, of which 96% were successful, and describes APT40 as favouring "exploiting public-facing applications over other traditional methods like phishing", often acting "within hours or days of the publication of proofs of concept".

The Essential Eight is a good baseline for the fleet. It was never the control set for the thing you sell.

We build software for Australian government and regulated clients, and we run the security work around it: secure code review, penetration testing, and Essential Eight assessment and uplift when the fleet is what needs attention. As a WA Government CUAICTS2021 panel supplier, we answer these questions in tenders often enough to know which ones actually get asked.