The Essential Eight and ASD Essentials for custom software projects

What changed in October 2026?

ASD published ASD Essentials on 15 October 2026, evolving the Essential Eight into a framework built on principles, actions and domains. Principles describe the security outcome, actions describe what to do to achieve it, and domains describe the business functions and assets the actions apply to. There are chapters for enterprise IT, cloud and operational technology, plus guides for implementation planning, assessment and moving across from the Essential Eight.

The Essential Eight itself was eight mitigation strategies measured against a maturity model. ASD first published that model in June 2017 and last revised it in November 2023. The eight strategies were:

1. Patch applications
2. Patch operating systems
3. Multi factor authentication
4. Restrict administrative privileges
5. Application control
6. Restrict Microsoft Office macros
7. User application hardening
8. Regular backups

ASD’s FAQ explains the shift in three parts: maturity levels give way to priority phases, a list of prescriptive requirements gives way to principles and actions that test whether outcomes are achieved, and domains let organisations focus on their critical business functions and systems. ASD says ASD Essentials is written mainly for Commonwealth entities, critical infrastructure and large organisations, while smaller businesses can still use it where relevant.

On timing, ASD says it has been talking to regulators and will advise on transition expectations in due course. Until it does, both frameworks are in play.

How do the old strategies map to ASD Essentials?

ASD’s transition guidance says every Essential Eight strategy maps to at least one ASD Essentials principle, and existing controls will often satisfy or contribute to its actions. The differences are scope, the broader outcomes some controls now feed, and the evidence needed to show an action works.

Essential Eight strategy	ASD Essentials principles it maps to	What it means for a custom application
Patch applications and patch operating systems	Vulnerability management, asset identification, legacy system management	Scan and patch the app, its libraries and runtime; keep an inventory; manage anything you can’t yet replace
Multi factor authentication	Identity, credential and access management	Phishing resistant MFA, plus secrets storage, unique credentials and removing legacy sign in protocols
Restrict administrative privileges	Identity, credential and access management; least privilege access; secure administration; network segmentation and segregation	Separate admin roles, time bound elevation, every admin change recorded, service accounts held to least privilege
Application control	Trustworthy software; secure configuration management	Mainly servers and devices, but administrative tooling must also be approved and controlled
Restrict Microsoft Office macros	Trustworthy software; secure configuration management	Rarely relevant unless the app produces or handles Office documents
User application hardening	Secure configuration management; content filtering	Configuration baselines for the environments you run, and limits on outbound connections
Regular backups	Regular and proven backups; least privilege access	Encrypted, isolated backups and restore tests that prove your recovery time and recovery point objectives

ASD also lists principles with no direct Essential Eight equivalent, including content filtering, cyber security awareness training and cyber supply chain security, and a Governance and culture domain covering areas such as supplier assurance, artificial intelligence accountability and legacy system management.

Do maturity levels still count?

Not as a rating under the new framework. ASD says Essential Eight maturity levels don’t automatically convert, because the old model measured implementation of specific controls against increasing attacker tradecraft, while ASD Essentials measures whether each action achieves its outcome for the assets in each domain.

Each action is rated not assessed, not effective, partially effective or fully effective, and a principle takes the lowest rating of its applicable actions in that domain. Priority phases set the order of work, not a level of assurance:

Priority phase	Domains	Where a custom application usually sits
Phase 1	Boundary services, identity services	An internet facing customer app and its sign in
Phase 2	Critical processes and services, privileged environments	Core systems the business depends on, and admin access to them
Phase 3	Business systems, user devices	Internal line of business apps and staff endpoints
All phases	Governance and culture, visibility and response	Ownership, risk decisions, logging and incident response

ASD’s FAQ gives a direct example: an internet facing customer application in an enterprise IT environment may be addressed under boundary services in phase 1 and critical processes and services in phase 2. The same controls are still implemented only once.

For organisations that reached Maturity Level Two, ASD expects many controls to feed the early phases, naming phishing resistant MFA, patching internet facing services, privileged access, application control and central logging. It also warns that Level Two doesn’t mean an action will be fully effective in every domain.

What if a contract or PSPF still names a maturity level?

Keep meeting it, and build the evidence so the same work counts under ASD Essentials. ASD’s transition guidance says organisations should continue to meet regulatory, contractual or other obligations that require Essential Eight implementation or reporting, and should report as directed by the relevant authority where Essential Eight terminology is still required.

PSPF Release 2026 still requires covered Commonwealth entities to implement each of the eight strategies to Maturity Level Two, and that requirement reaches suppliers where a deed or agreement says so. Insurers, government panels and enterprise security schedules may also still ask for a level.

In practice:

1. Read the clause. Note the level, the scope and whether self assessment is accepted. That is your obligation until the clause changes.
2. Don’t start work only to hit a superseded target. ASD advises against it unless a regulator or other obligation still requires it, or the work still addresses material cyber security risk.
3. Map planned work to ASD Essentials first. ASD recommends this before deciding whether planned work continues unchanged.
4. Keep evidence of operation, not just deployment. ASD says configuration records show what was deployed, but ratings under the new framework draw on validation results, monitoring records, restore tests and similar proof over time.
5. Ask the buyer about the transition. Whether a panel or contract will move to ASD Essentials is the buyer’s decision, and ASD hasn’t yet set the timeframes.

What patching timelines apply?

Under the Essential Eight maturity model, critical vulnerabilities in online services must be patched within 48 hours of release, or when working exploits exist, from Maturity Level One upwards. These are still the numbers a contract naming a level will test.

Requirement (November 2023 model)	Level One	Level Two	Level Three
Vulnerability scan of online services	At least daily	At least daily	At least daily
Patch online services: critical or working exploit	48 hours	48 hours	48 hours
Patch online services: other vulnerabilities	2 weeks	2 weeks	2 weeks
Scan other applications	Not specified	At least fortnightly	At least fortnightly
Patch other applications	Not specified	Within one month	Within one month
Remove unsupported online services	Required	Required	Required

ASD Essentials phrases this differently: apply patches within defined risk based timeframes, or automatically where operational impact is low, and remediate vulnerabilities above a risk threshold based on exploitation, exposure, criticality, impact and compensating controls. ASD notes that ISM, regulatory and other mandatory timeframes continue to apply, and that a suitable timeframe can differ between domains.

For a custom application, patching includes upgrading vulnerable open source packages. A two day turnaround is only realistic with automated dependency scanning, a test suite you trust and a pipeline that can ship a patched build the same day.

What must the application do for MFA and credentials?

Under the Essential Eight, online customer services holding sensitive customer data need MFA for customers from Maturity Level One, with a phishing resistant option at Level Two and phishing resistant MFA required at Level Three. Staff using online services need phishing resistant MFA from Level Two, which also requires successful and failed MFA events to be centrally logged.

ASD Essentials keeps phishing resistant MFA and widens the principle. Its identity actions also ask organisations to:

• store keys, secrets and tokens in approved secure repositories with access controls, including MFA
• regularly scan codebases, configuration files, file shares and collaboration platforms for unsecured secrets
• disable legacy authentication protocols, or restrict, monitor and plan to retire them
• keep user, machine, system and service account credentials unique per system or account
• remove default and unused accounts on a regular basis

Most of that is engineering work inside the product and its pipeline, so it belongs in the first release, not a later uplift.

How should admin access, logging and backups be built?

Build separate privileged roles, grant elevated access for a set time, record every change, and make backups that can be restored and can’t be quietly deleted. The Essential Eight’s Level Two disables privileged access after 12 months unless revalidated and after 45 days of inactivity; Level Three adds just in time administration and backups even backup administrators can’t change during retention.

ASD Essentials adds actions that land directly on a custom system:

• explicit session controls before privileged actions, including time bound privilege grants
• a record of every administrative change to systems, configuration or controls, with the user, time and target
• least privilege for service and other non person accounts, not just people
• backups on a defined schedule to encrypted storage protected by immutable, offline or logically isolated controls, kept apart from production
• restore tests that show recovery time and recovery point objectives can be met
• security relevant logs forwarded to a central capability that can correlate events across systems

A checklist for your next software project

Put these into the requirements before development starts; each is cheap early and expensive later.

1. Record any obligation that names an Essential Eight level, and agree which ASD Essentials chapter and domains the system falls under.
2. Automated dependency and container scanning on every build, routed to a named owner.
3. A pipeline that can release a tested patch within 48 hours.
4. A register of components, libraries, runtimes, identities and data stores, with support end dates.
5. Phishing resistant MFA for staff and admins, and for customers where sensitive data is held or the contract asks for it.
6. Secrets in a managed store, secret scanning on the codebase, and no legacy sign in protocols.
7. Separate admin roles with time bound elevation, and a log of every admin change.
8. Central, protected logging of authentication, admin and security events.
9. Encrypted, isolated backups with scheduled restore tests against agreed recovery objectives.
10. Written exceptions with compensating controls, approved, time bound and reviewed.

Beyond either framework

Both frameworks set a floor for an organisation, not a full application security program. Application risks such as broken access control, injection and, for AI systems, prompt injection need their own controls. ASD’s FAQ says ASD Essentials treats AI as another asset to include in scoping. If your buyers are agencies, the IRAP guide explains assessments against the ISM. For APRA regulated clients, read CPS 234 and AI systems. For budgets, see what an Essential Eight uplift costs.

One point matters for suppliers. ASD says outsourcing a service doesn’t transfer accountability for its security outcomes, and a domain shouldn’t be treated as effective just because a third party is responsible for it. Expect buyers to ask you for current evidence, not a one off assurance.

How AWLabs builds for it

We don’t assess or certify Essential Eight maturity or ASD Essentials effectiveness, we don’t claim a level or rating for any client, and AWLabs is not CREST accredited and holds no certification. We build software so the relevant controls are achievable and the evidence exists: dependency and secret scanning as quality gates on every change, a pipeline that can ship a patched build quickly, MFA and role based admin access designed in, admin and authentication events logged, and backups designed for restore, in Australian regions where that is written into your Schedule of Work. Senior engineers lead every build.

The first call is a Development Consult, held in Sydney business hours, where we look at what your contract or buyer actually asks for. Scoped work then comes as a fixed price Schedule of Work with three options. Keeping patch timelines over years is an operations commitment, so see our cybersecurity and software maintenance and support services.