The ACSC Essential Eight: Delivering MFA for all Australians

Australian government agencies will soon be expected to apply multi-factor authentication (MFA) to the digital services they provide to the Australian public, as part of a substantive overhaul to the ACSC’s Essential Eight Maturity Model.

The Essential Eight is a set of priority controls agencies are expected to implement to mitigate cyber security incidents. The eight control categories remain the same: government agencies are still expected to implement application control and multi-factor authentication, to restrict administrative privileges, to patch operating systems and applications, to backup regularly and to harden browsers and Office apps. But the ACSC’s Maturity Model, which provides detailed requirements for each of these eight controls, has been overhauled to reflect changes in the operating and threat environment. These include important changes to where multi-factor authentication should be applied.

Up until now, it advised government agencies to apply multi-factor authentication to protect the remote access sessions of the public sector workforce.

Under the updated advice, a baseline level of maturity (Maturity Level 1) demands that MFA is applied to a far broader range of contexts:

• When the workforce authenticates to internet-facing services;
• When the workforce authenticates to cloud services that process or store the agency’s data, and;
• When non-employees (Australian residents) connect to the agency’s internet-facing services.

This third requirement is a laudable commitment to protecting Australians against identity theft and fraud. Multi-factor authentication is one of the simplest and most powerful protections against a variety of threats. It has been mandated and endorsed in plenty of contexts, but the ACSC deserves credit for pushing for it to be applied universally.

Rethinking factors

The Maturity Model has also been revised to anticipate shifts in what forms of multi-factor authentication prove most effective. 

Rather than being prescriptive about specific factors (password vs. fingerprint, etc.), the revised maturity model gauges maturity based on factor types (something you know, something you have, something you are).

We’ve come along a similar journey at Okta. In April 2021, Okta announced the Early Access availability of Authenticators, a new concept in the policy engine of the Okta Identity Platform that closely aligns with NIST 800-63B standards. 

Instead of setting policies based on specific factors, Okta admins can specify one or two factor types of authentication and characteristics that provide the right level of protection for access to any given app.

To illustrate, the Okta Verify mobile app is an authenticator. But by design, the level of assurance Okta Verify can offer is flexible. It could be used as a possession type (when using “push” method) or it could be a possession + biometric type when enrolled on a device that requires a facial recognition scan to open the app. 

Under Okta’s Authenticators concept, Okta admins can set a sign-on policy for specific apps to require a combination of these factor types, as well as some specific characteristics or attributes such as “device bound,” “hardware protected,” or “phishing resistant.” Okta’s policy engine then prompts users for the authenticators enrolled that allow them to meet the precise assurance requirements specified in policy. The full range of factor types available in the Okta identity cloud are available on our website.

This policy engine -- and Okta’s vendor-agnostic approach to authenticators -- makes it effortless to progress from one maturity level to the next as agencies require. It also ensures that Okta customers can easily adapt to future shifts in adversary tradecraft, as well as any new guidelines put forward to address those threats.