AI Summary Box
The ACSC Essential Eight is a set of eight prioritised cybersecurity mitigation strategies developed by the Australian Signals Directorate (ASD), mandatory for non-corporate Commonwealth entities under the PSPF, and it is also commonly used as a security baseline in government and regulated supply-chain contexts. The framework was developed in response to common enterprise attack paths, many of which historically appeared in Windows and Microsoft Office environments. This guide maps all eight Essential Eight controls to their DevSecOps equivalents, with a maturity roadmap Australian software teams can act on without grinding development velocity to a halt.
Most Australian software teams treat the Essential Eight as someone else's problem. They hand it to IT ops, let it sit in a compliance spreadsheet, and move on.
That's an increasingly expensive assumption.
Several Essential Eight controls have practical equivalents inside modern SDLC and DevSecOps workflows. Build pipelines, dependency management, developer access controls, and repositories are common places where Essential Eight-aligned controls can be implemented. As cyber insurers and government procurement teams tighten requirements in 2026, "we left it to IT" is not a defence.
The good news: the framework is more developer-compatible than it looks. It just needs translating.
Building software that needs to meet the ACSC Essential Eight? Talk to Hireplicity about secure software development for Australian compliance environments.
In This Guide
What Is the ACSC Essential Eight — and Why Do Software Teams Own Part of It?
The ACSC Essential Eight is a prioritised set of eight cybersecurity mitigation strategies developed by the Australian Signals Directorate (ASD) and maintained by the Australian Cyber Security Centre (ACSC). It defines the minimum security baseline every Australian organisation with internet-connected systems should implement.
First published in 2017 and updated regularly, the framework came directly from ASD's hands-on experience responding to real cyber incidents across Australian government agencies and businesses. Every control maps to an attack vector that adversaries have actively exploited against Australian organisations — it is not a theoretical checklist.
The Essential Eight is mandatory for all non-corporate Commonwealth entities under the Protective Security Policy Framework (PSPF), which requires a minimum of Maturity Level 2. Since November 2025, Defence Industry Security Program (DISP) members must also hold ML2 across all eight controls — a change that has pushed compliance expectations down through the broader Australian government supply chain, affecting private sector vendors.
For software development teams, the critical insight is this: you own more of this framework than you think.
Essential Eight Control Owners Matrix
| Essential Eight Control | Primary Owner |
|---|---|
| Application Control | Shared (IT Ops + Dev) |
| Patch Applications | Dev Team |
| Configure Microsoft Office Macro Settings | IT Ops |
| User Application Hardening | Shared (IT Ops + Dev) |
| Restrict Administrative Privileges | Shared (IT Ops + Dev) |
| Patch Operating Systems | Dev Team (base images) |
| Multi-Factor Authentication | Shared (IT Ops + Dev) |
| Regular Backups | Shared (IT Ops + Dev) |
If your engineering team has no involvement in at least five of these controls, your cybersecurity posture has a gap — and your compliance status is likely overstated. Some industry reports estimate the average cost of cyber incidents for Australian small businesses at more than $46,000. (ACSC 2024–25 Cyber Threat Report, via Netcomp Solutions). For a company building software for government clients or handling sensitive user data, a single breach can cost far more than that.
The Essential Eight Was Built for Windows Networks — Not Your CI/CD Pipeline
The Essential Eight was initially shaped around common enterprise environments, including Windows and Microsoft Office ecosystems. Most Australian software teams in 2026 run something entirely different: containerised microservices, SaaS development tooling, cloud-native infrastructure on AWS, and remote developer teams on their own devices.
In DevSecOps settings, the framework often needs interpretation to map control intent to cloud and CI/CD workflows. "Application Control" reads like an IT policy. "Patch Applications" sounds like a sysadmin task. "Configure Microsoft Office Macro Settings" has no obvious home in a Node.js team.
The underlying security intent behind each control is entirely relevant to software development. The controls just need a DevSecOps lens.
In this article, we use the ‘E8-to-SDLC Translation Stack’ to describe a mapping of each Essential Eight control to its functional equivalent in a modern software development environment.
The E8-to-SDLC Translation Stack
| Essential Eight Control | DevSecOps Equivalent |
|---|---|
| Application Control | A practical DevSecOps analogue for Application Control is to build artifact governance, dependency allowlisting, and signed container images. |
| Patch Applications | Automated dependency scanning in CI/CD (Dependabot, Snyk, OWASP) |
| Configure Office Macro Settings | Restrict scripting and automation in developer tooling and CI pipelines |
| User Application Hardening | Hardened dev environments, browser profiles, IDE security policies |
| Restrict Administrative Privileges | Least-privilege IAM for developer accounts, service accounts, cloud roles |
| Patch Operating Systems | Immutable infrastructure, base image freshness, OS-level CVE scanning |
| Multi-Factor Authentication | Phishing-resistant MFA for repos, cloud consoles, and CI/CD systems |
| Regular Backups | Database backups, config-as-code, secrets backup, restoration testing |
Building security into the SDLC at development time costs a fraction of what it costs to retrofit after a breach — or after a government contract audit surfaces gaps in your compliance posture.
How Each Essential Eight Control Applies to Your Development Lifecycle
1. Application Control → Dependency and Build Artifact Governance
Application Control means ensuring only approved software can execute in your environment. For software teams, that means governing what enters your build pipeline — not just what runs on end-user machines.
In a CI/CD context, this looks like maintaining approved dependency registries, enforcing signed container images, and blocking unapproved packages from entering your build. A compromised npm package or a backdoored base image is the developer-world equivalent of an unauthorised executable.
Practical starting point: enforce a private package registry (AWS CodeArtifact, JFrog Artifactory) that proxies public repositories so your team can audit or block packages before they reach production builds.
Unsure where your build pipeline stands against the Essential Eight?
Hireplicity can help you assess and close the gaps.
2. Patch Applications → Automated Dependency Scanning in CI/CD
The Essential Eight requires patching known application vulnerabilities within 48 hours for critical risks. In a software development context, your third-party dependencies are in scope — not just your production servers.
Most Australian dev teams patch on a sprint cycle. That is too slow for the current threat environment. Tools like Dependabot, Snyk, or OWASP Dependency-Check integrate directly into GitHub Actions or GitLab CI and flag CVEs the moment a dependency version is compromised — generating automated pull requests for your team to review rather than requiring manual vulnerability hunts.
The ACSC recorded over 120 incidents from attacks on edge devices in FY2024–25, with a 96% success rate (CyberCX 2026 Threat Report, via Netlogyx IT). Unpatched dependencies in production code carry the same risk profile as an unpatched edge device.
3. Configure Microsoft Office Macro Settings → Restrict Scripting in Developer Tooling
At its core, this control blocks untrusted code execution through automation vectors. For dev teams, the principle applies to CI/CD scripts, pre-commit hooks, and shell scripts pulled from external sources.
The original control targets macro-based malware delivered through Office documents. The developer-world equivalent is a malicious script embedded in a third-party GitHub Action, a compromised pre-commit hook, or unvetted automation tooling. Vet and pin CI/CD action versions. Avoid pulling from "latest" references in build pipelines — pin to a specific commit SHA so you control exactly what executes.
4. User Application Hardening → Harden Developer Environments
User Application Hardening reduces the attack surface in the applications your team uses daily — browsers, document readers, and productivity tools. For dev teams, this extends to IDE plugins, browser extensions, and local build tooling.
Harden developer machines through configuration management (Ansible, Puppet) or endpoint management platforms (Jamf for macOS, Intune for Windows). Restrict IDE extensions to an approved list. Disable unnecessary browser plugins on developer machines. These controls close real attack vectors — attackers regularly use a compromised developer machine as the pivot point into a codebase or cloud environment.
5. Restrict Administrative Privileges → Least-Privilege IAM for Developer and Service Accounts
Restricting administrative privileges means people and systems only hold the access they actually need. For software teams, this is primarily an IAM problem — not a desktop IT problem.
Developer accounts frequently hold broader cloud permissions than their actual role requires. Service accounts in CI/CD pipelines often carry admin-level access granted "temporarily" during initial setup and never reviewed. The Principle of Least Privilege (PoLP) applies directly: scope every IAM role to the minimum permissions required for the specific task.
For Maturity Level 3, implement Just-In-Time (JIT) access for elevated permissions — temporary, auditable, time-bounded elevation instead of persistent admin roles. AWS IAM Identity Center and Azure PIM both support this natively.
6. Patch Operating Systems → Immutable Infrastructure and Base Image Freshness
The Essential Eight requires patching operating system vulnerabilities rated "extreme risk" within 48 hours. For cloud-native teams, the equivalent is maintaining fresh, vulnerability-scanned container base images and rebuilding from source regularly rather than patching live containers.
Immutable infrastructure is the DevSecOps answer to OS-level patching. Rather than applying patches to running systems, you rebuild containers from a known-good, regularly updated base image and redeploy. Integrate OS-level CVE scanning into your container build pipeline using tools like Trivy or Grype. Flag any base image with known critical vulnerabilities before it reaches a deployment stage.
7. Multi-Factor Authentication → Phishing-Resistant MFA Across Developer Tooling
The Essential Eight requires MFA across all remote access points, privileged accounts, and data repositories. For software teams, that scope includes GitHub or GitLab, your cloud console, your CI/CD platform, and every system a developer accesses remotely.
This is where most Australian dev teams fall short. Many have MFA enabled — but on SMS codes or basic authenticator push notifications that no longer satisfy the ASD's requirements.
ACSC guidance now emphasizes phishing-resistant MFA for stronger maturity levels, so SMS-only MFA should not be treated as sufficient for privileged access. The CyberCX 2026 Threat Report confirms that attackers now bypass most standard MFA through adversary-in-the-middle session hijacking using low-cost, widely available phishing kits.
For stronger maturity levels, ACSC guidance requires phishing-resistant MFA in relevant contexts, including privileged access. That means FIDO2 hardware security keys (YubiKey), platform authenticators (Touch ID, Windows Hello), or certificate-based authentication. Enforce this on your GitHub or GitLab organisation settings, AWS root account and all IAM users, CI/CD platforms (CircleCI, GitHub Actions), and any developer-facing admin panels.
8. Regular Backups → Databases, Config State, and Secrets
The Essential Eight requires daily backups of critical data stored disconnected from the network, with restoration tested regularly. For software teams, this means databases, infrastructure-as-code state, environment configuration, and — critically — your secrets management vault.
The ransomware risk to software teams extends beyond production data. Configuration drift, infrastructure state, and secrets that cannot be reconstructed are equally valuable targets for attackers.
Use automated daily snapshots for databases (AWS RDS automated backups with point-in-time recovery). Store Terraform state remotely with versioning enabled. Test restoration quarterly — not just backup creation.
Treat your secrets management vault (HashiCorp Vault, AWS Secrets Manager) as a primary backup target. A secrets vault with no verified restoration path is a single point of failure most recovery plans have not accounted for.
Essential Eight Maturity Levels: What They Mean for a Software Team
The Essential Eight Maturity Model defines four levels (ML0–ML3). An organisation’s maturity is assessed across all controls, so one weak control can limit the overall maturity outcome. If your MFA is strong but your patching is inconsistent, your organisation sits at ML1, regardless of how well everything else is configured.
Controls largely absent. No formal dependency scanning, no MFA enforcement on dev tooling, ad-hoc or no patching cadence. High exposure to opportunistic attacks.
Basic controls in place but inconsistently enforced. MFA enabled but SMS-based. Dependencies patched on a sprint cycle rather than within 48 hours. Manual or irregular vulnerability scanning.
Controls repeatable and monitored. Phishing-resistant MFA enforced for privileged accounts. Automated dependency scanning integrated into CI/CD. IAM roles scoped by least privilege. Backups tested regularly. This is the common target for PSPF-aligned environments and many government supply-chain requirements.
Proactive, fully automated controls. Just-In-Time privilege elevation. Immutable infrastructure with automated CVE scanning at build time. Continuous monitoring integrated with a Security Operations Centre (SOC). Required for critical infrastructure and IRAP-assessed environments.
For most Australian software companies working with government clients or regulated industries, ML2 is the practical target. Reaching it from ML0 or ML1 typically takes 3–6 months on a modern cloud stack, with the longest lead time usually in IAM remediation and phishing-resistant MFA rollout.
The 3 Most Common Essential Eight Cybersecurity Gaps in Australian Dev Teams
These are the three cybersecurity controls Australian software teams most consistently get wrong, based on ACSC incident data and ASD guidance.
-
1. Phishing-resistant MFA is not enforced on development tooling
Most teams have MFA. Few have phishing-resistant MFA on code repositories, cloud consoles, and CI/CD platforms. SMS codes and standard push notifications do not satisfy ML2 for privileged accounts. This gap is the most actively exploited in the current Australian threat environment. -
2. Dependency patching runs on sprint cycles, not vulnerability timelines
The Essential Eight requires critical patch deployment within 48 hours. Most dev teams operate on a two-week sprint cycle at best — and only when someone on the team manually checks. Automated dependency scanning with CI/CD-integrated alerting closes this gap without adding meaningful developer overhead. -
3. Service account and IAM role sprawl
CI/CD pipelines, deployment automation, and cloud-native services accumulate overpermissioned service accounts over time. An account created with admin-level access "temporarily" during initial setup is often still admin a year later. Regular IAM audits and tightly scoped role definitions are the remediation — and they are frequently the difference between a minor incident and a full environment compromise.
Deep-Dive FAQs
It is mandatory for non-corporate Commonwealth entities under the PSPF, which requires Maturity Level 2. For private Australian software companies, it is not legally required — but it is increasingly expected to win government contracts, pass IRAP assessments, and qualify for cyber insurance. Since November 2025, DISP supply chain members must demonstrate ML2 across all eight controls.
Yes, though the framework requires translation from its on-premises Windows origins. The ASD confirms that the underlying security principles apply to cloud environments. Under the shared responsibility model, tenant-level controls — including IAM, MFA, patching, and backup — remain the software team's responsibility regardless of cloud provider.
ISO 27001 is a broad international governance framework covering policies, risk management, and organisational security processes. The Essential Eight is a prescriptive, technically specific set of controls mapped directly to Australian threat vectors. Many Australian companies pursue both: ISO 27001 for governance certification, and the Essential Eight for technical control compliance. For dev teams, the Essential Eight is more immediately implementable.
Not for Maturity Level 2 or above on privileged accounts. The ASD formally deprecated SMS MFA for privileged access in the November 2023 framework update. Accepted phishing-resistant alternatives include FIDO2 hardware security keys, platform authenticators (Touch ID, Windows Hello), and certificate-based authentication.
The time to reach ML2 varies by current controls, IAM complexity, and MFA rollout. The main variables are the current state of IAM roles (typically the most time-consuming to remediate), existing MFA enforcement, and technical debt in dependency management. Teams starting from ML0 should plan toward the longer end of that range.
Conclusion: Security Built Into the SDLC, Not Bolted On After
The ACSC Essential Eight is not an IT compliance task you can hand off and revisit at audit time. For Australian software development teams, at least five of the eight controls live inside your SDLC — in CI/CD pipelines, IAM configuration, MFA enforcement, dependency management, and backup strategy.
The teams that handle this well do not retrofit compliance after the fact. They build it into the development process from day one: automated scanning in the pipeline, least-privilege access by default, phishing-resistant MFA at the organisation level, and container infrastructure rebuilt from clean base images on a regular cadence.
That is how you reach Maturity Level 2 without disrupting development velocity — and the only posture that holds up when a government client or cyber insurer asks for evidence.
At Hireplicity, we have been delivering secure software development for Australian and U.S. clients for over 16 years. We know how to apply cybersecurity frameworks — including the Essential Eight — inside a working SDLC without turning engineering into a compliance treadmill.
Building software for the Australian government supply chain or heading toward an IRAP assessment? We can help you build E8-aligned software from the ground up. Get in touch with Hireplicity.
Build Security Into the SDLC with Hireplicity
Ensure your software, pipelines, and cloud environments satisfy ACSC Maturity Level 2 criteria. Work with our secure, highly-specialized engineering teams in Cebu City and Utah.
Sources & References
- Australian Cyber Security Centre — Essential Eight Explained
- Australian Cyber Security Centre — Essential Eight Maturity Model
- ACSC 2024–25 Cyber Threat Report (via Netcomp Solutions) — Threat Analysis Data
- CyberCX 2026 Threat Report (via Netlogyx IT) — Cyber Incident Mitigations Study
- DISP ML2 requirement update, November 2025 (via Communicat) — Maturity Level 2 Government Timeline
- SecureStack — Essential8 SDLC Mapping Project
