Open source SSO for Essential Eight MFA

How Essential Eight MFA maturity levels shape a workforce SSO design

If your organization is aligned to the Essential Eight, start by understanding what it asks for. The *Essential Eight* is a set of mitigation strategies published by the Australian Signals Directorate, not a certification scheme, so there is no ASD certificate to obtain. Maturity is shown by assessing how each strategy is implemented and how well it works against the maturity model. For multi-factor authentication, the requirements are tagged by control IDs in the Information Security Manual. The ISM OSCAL catalog tags seven MFA controls at ML1 (including ISM-1504 and ISM-1401), six more are added at ML2, and ISM-1505 and ISM-1894 are the ML3 controls. The phishing-resistant requirement arrives at ML2 for human users of online services and systems (ISM-1872 and ISM-1682), and at ML3 for human users of data repositories (ISM-1505 and ISM-1894).

The identity provider is only part of the evidence. ML1 and ML2 coverage depends on whether MFA is enforced on every path that reaches sensitive data, including privileged and unprivileged system users, third-party online services and customer-facing services. Your SSO design should therefore start with an inventory of applications, their protocols and the accounts that bypass the identity provider. Ask your implementation partner to confirm how each application is enforced through the realm or flow configuration in Keycloak, or through the authentication flow and policy bindings in authentik, and which applications sit outside SSO and need a separate control. Confirm the exact phishing-resistant method (for example, passkeys or WebAuthn-based authenticators) your ML2 and ML3 scope requires with your assessor before you pick it.

DeployOpen plans, configures and documents the identity platform and prepares the configuration exports, test records and access reviews that an assessor will ask for. It does not issue assessments, attestations or maturity ratings. The ISM OSCAL catalog and the Assessment evidence guide for enterprise IT are the right starting points for mapping your evidence to controls, and your internal or external assessor makes the final judgment. Before work starts, agree in writing which Essential Eight maturity level is the target, which systems are in scope for each strategy, and who owns the evidence from the identity platform after handover.

Which MFA controls apply at each Essential Eight level and what the SSO must do

This table maps the ISM controls tagged to MFA at Essential Eight maturity levels one to three to what the identity provider must enforce. Read each row as a requirement the SSO configuration must satisfy, then confirm the control wording and applicability in the ISM and your own assessment scope.

Control and level	What the control asks in plain terms	What the SSO must enforce	Keycloak or authentik configuration notes
ISM-1504 and ISM-1679 (ML1)	MFA must protect human access to the organisation's own and third-party online services that handle sensitive data.	Every browser-based login to sensitive SaaS and internal portals passes through the identity provider with a second factor.	Set a browser flow with an OTP or WebAuthn step as required for the relevant clients, and confirm each application client uses the realm or tenant flow.
ISM-1680 (ML1)	MFA covers third-party online services holding non-sensitive data where the service supports it.	Apps that accept federated login are routed through the identity provider, and the second factor applies wherever the service allows it.	Inventory SAML and OIDC clients, then mark which ones cannot enforce a second factor so the exceptions are documented.
ISM-1173 and ISM-0974 (ML2)	MFA must cover both privileged and unprivileged users of systems, not only users of online services.	Operating system, VPN, remote desktop and admin consoles need authentication backed by the identity provider or an equivalent second factor.	Use LDAP or Kerberos federation with a second-factor step, or a proxy or RADIUS provider in authentik, and confirm each system path is covered.
ISM-1892 and ISM-1893 (ML2)	Staff must use MFA for own and third-party online customer services holding sensitive customer data.	Staff access to customer data tools requires MFA, and privileged staff roles get stricter checks.	Create a group-based authentication policy or conditional flow that forces MFA for staff roles tied to customer data applications.
ISM-1681 (ML2)	Customers of online services holding sensitive customer data must use MFA.	Customer-facing logins apply a second factor, separate from staff policy.	Keep customer logins in a separate realm or tenant with its own flow, so staff policy changes do not weaken customer MFA.
ISM-1872 and ISM-1682 (ML2, phishing-resistant)	MFA for human users of online services and systems must resist phishing.	Second factors must be phishing-resistant, so SMS and one-time codes alone do not satisfy the rule.	Require WebAuthn or passkey credentials in the authentication flow and remove OTP-only fallbacks for these groups. Confirm the exact ISM wording with ASD.
ISM-1873 (ML2, customer option)	Online customer services must offer customers a phishing-resistant MFA option.	At least one phishing-resistant method must be available to customers, even if it is not mandatory.	Enable WebAuthn or passkey registration in the customer flow and test enrollment from a customer account.
ISM-1874 (ML3, customer MFA)	At ML3, MFA for customers of online customer services must be phishing-resistant.	Customer login cannot fall back to non-phishing-resistant factors once ML3 applies.	Make the WebAuthn or passkey step required in the customer flow, and review account recovery paths that could bypass it.
ISM-1505 (ML3, data repositories)	MFA must authenticate human users of data repositories.	Database, file store and data platform logins are covered by the second factor through the identity provider or an approved proxy.	Confirm which repositories support OIDC or LDAP federation. Where they do not, document the compensating access path and its owner.
ISM-1894 (ML3, repository phishing resistance)	MFA for data repository users must be phishing-resistant.	Repository access uses passkeys or WebAuthn, not one-time codes.	Apply a WebAuthn-required step to repository clients and confirm the passkey policy (user verification, attestation) with your assessor.

What changes at ML1, ML2 and ML3 for workforce login

Maturity Level One sets the first MFA requirements. The ISM v2026.09.4 Essential Eight profiles contain 46 ISM controls at ML1, and the ML1 MFA controls cover human users of the organisation's own online services and of third-party services that process or store sensitive data. Phishing resistance is not yet required at this level, so an authenticator such as a one-time code can satisfy the baseline if it is applied consistently.

Who needs MFA: Human users of the organisation's own and third-party online services that handle sensitive data (ISM-1504, ISM-1679), and third-party services holding non-sensitive data where available (ISM-1680).
Systems access: Privileged and unprivileged human users of systems, not only users of online services, must authenticate with MFA (ISM-1173, ISM-0974 are tagged as additions at ML2, so confirm your scope against the ML1 profile).
Customer services: Staff authentication to sensitive customer services and customer authentication to sensitive customer services are covered by ML1 controls (ISM-1892, ISM-1893, ISM-1681).
Phishing resistance: Not mandated at this level.
Inheritance: Every ML1 control is also in ML2, so the ML1 design carries forward.

Confirm the exact control list for your scope in the ISM OSCAL profiles before you design the identity provider, since the mapping of controls to levels is what an assessor will check.

How passkeys and WebAuthn meet phishing-resistant MFA in Keycloak and authentik

Phishing resistance means the credential cannot be replayed or handed to a look-alike site. A WebAuthn or passkey credential is bound to the origin it was registered for, and the secret never leaves the authenticator as a value a user can type into a page. That binding is what the ISM controls mean when they require phishing-resistant MFA at ML2 for online services and systems (ISM-1872, ISM-1682) and at ML3 for data repositories (ISM-1894) and customer services (ISM-1874). A one-time code typed into a form does not have that property, so the design question is whether each factor a user can actually reach is origin-bound. Keycloak supports WebAuthn and passkey registration as required actions and as authentication flow steps, and authentik supports FIDO2 authenticators as an authenticator stage. Confirm the exact flow configuration, the attestation settings and the relying party ID for each realm or tenant with your assessor and against the current product documentation for your version.

Fallback methods are where the control is most often lost. If a user can still complete sign-in with TOTP, SMS or an email code, an attacker who phishes the password and the code can succeed, so the fallback path sets the real assurance level. Treat TOTP and SMS as methods you must justify, not as defaults. Decide which users may keep a non-phishing-resistant method, for how long, and whether it is blocked for privileged accounts and administrative consoles. Recovery needs the same scrutiny: a help-desk reset that issues a new password with no identity check undermines the passkey entirely. Document the enrollment path, the recovery procedure, the number of registered authenticators allowed per user and the audit events generated when a factor is added or removed. Confirm with your assessor whether each method counts as phishing-resistant under your ASD assessment scope before you describe it in evidence.

Which open-source identity platforms fit an Essential Eight MFA design

Essential Eight MFA at maturity levels one to three depends on which identity provider can enforce MFA for every human user and offer phishing-resistant factors at ML3. The four options below differ in license, supported factors, directory integration and which features sit behind a paid tier, so the choice should follow from the controls your organization must meet.

Keycloak for broad protocol coverage

Keycloak is licensed under Apache-2.0 and supports OpenID Connect, OAuth 2.0 and SAML 2.0, with LDAP and Active Directory user federation for existing directories. Its high availability designs require a synchronously replicated database, so the database tier is part of the MFA availability case. Confirm which WebAuthn or passkey flows your target applications accept and test them against the ML3 phishing-resistance requirement before committing to a design.

authentik with paid enterprise features

The authentik core is MIT licensed, but the authentik/enterprise directory uses a separate license. Per the authentik pricing page, mTLS client certificate authentication and privileged access management are enterprise-only, so an ML3 design relying on certificate-based or privileged controls must budget for that subscription. Since 2025.10 authentik runs on PostgreSQL without Redis, which simplifies the stack but adds database connection load to plan for.

ZITADEL for passkey-first login

ZITADEL is licensed under AGPL-3.0, which requires careful review if you modify the software and make it available to users over a network. Its README lists MFA, passkeys (FIDO2 and WebAuthn), SAML 2.0 and SCIM, which maps well to phishing-resistant staff login. Ask your legal team to review AGPL obligations, then confirm the passkey enrollment, recovery and fallback flows that auditors will sample as evidence.

FreeIPA for Kerberos environments

FreeIPA suits Linux-heavy estates that already rely on Kerberos, LDAP and an internal certificate authority. It can anchor workforce identity for SSH and desktop logins, with Keycloak or another broker placed in front of web applications. The design question is whether your MFA factors and certificate-based login can be enforced for every privileged and unprivileged user, and whether the Kerberos path meets the phishing-resistance expectations at ML3. Confirm this with a proof of concept before selecting it.

How an Essential Eight MFA rollout is sequenced

The sequence turns Essential Eight MFA from a list of control IDs into a scoped inventory, a supported identity provider, phishing-resistant enrollment and tested recovery paths. Each step ends with evidence an assessor can review.

Scope systems and online services by maturity level
The organization's security and compliance leads, with system owners, list every internal system, third-party online service and customer-facing service that processes or stores sensitive data. Each entry is tagged with the ISM controls that apply at the target maturity level (ML1, ML2 or ML3) and whether the path is privileged or unprivileged. The output is a signed scope register that maps each system to its MFA requirement, including which services must be phishing-resistant at ML3. Confirm the mapping against the current ISM OSCAL Essential Eight profiles before procurement starts.
Deploy the identity provider on a supported database
The platform team deploys Keycloak or authentik in the organization's own infrastructure, using a production database from the supported list for the chosen platform. For Keycloak, the team confirms the high availability design requires a synchronously replicated database and uses the Operator where it fits the platform. The output is a running cluster, tested backups and a documented upgrade path. Confirm the supported database versions and high availability topology with the vendor documentation before build.
Pin operator updates to manual approval
Platform engineers configure the Keycloak Operator to use manual approval mode for updates, since the Operator documentation strongly recommends this to avoid unintended automatic upgrades. Each release is tested in a non-production realm that mirrors production clients, protocols and MFA flows before approval. For large deployments, the team decides in advance whether database schema migration runs at startup or is applied manually as SQL. The output is a change record showing who approved each version and the test results that supported it.
Enroll staff in WebAuthn or passkeys
The identity team configures WebAuthn or passkey authentication as the primary second factor, with a documented fallback that does not weaken phishing resistance. Staff enroll in controlled waves, starting with privileged accounts and users of the highest-risk services, and help desk staff verify identity before resetting any factor. Enrollment reports show coverage by group and by system scope. The output is an enrollment record for each account, reviewed against the scope register from the first step.
Enforce MFA on privileged and unprivileged paths
Administrators bind MFA to every sign-in path in the scope register, covering both privileged and unprivileged users of systems and online services. Application clients are configured for OpenID Connect or SAML so that no application bypasses the identity provider, and legacy applications that cannot use SSO are listed with compensating controls. Authentication flows are tested with a sample of users per group, and failed or bypassed sign-ins are logged. The output is a test report showing each path requires phishing-resistant MFA where the target level demands it.
Test recovery and break-glass access
The identity and security teams rehearse lost-authenticator recovery, identity provider outage and emergency administrator access in a non-production environment. Break-glass accounts are stored under dual control, and each use generates an alert and a review ticket. The rehearsal records the time to recover, which the team compares against its own service objectives rather than a published benchmark. The output is a signed test record and a corrected runbook, which assessors can use as evidence that MFA does not leave staff locked out.
Collect assessment evidence and review scope
The compliance lead collects configuration exports, enrollment reports, change approvals, audit logs and recovery test records, and maps each to the Essential Eight strategy and ISM control it supports. The team reviews the scope register against new systems and staff changes, then schedules the next review. DeployOpen prepares these artifacts for assessment, but the independent assessor decides whether the maturity level is met. The output is an evidence pack and a dated scope review that a third party can trace from control to configuration.

What assessors ask for as MFA evidence and which component produces it

This table maps each piece of MFA evidence an assessor typically asks for against the component that produces it in a self-hosted Keycloak or authentik deployment. Read each row as a question to answer before the assessment, and confirm the exact format and retention period with your assessor. The main takeaway is that most evidence comes from configuration exports and logs you must retain on purpose, not from the running system alone.

Evidence item	Component that produces it	What to confirm with the assessor
Authentication flow and policy exports	Keycloak realm export of authentication flows and required actions; authentik flow and stage configuration export	Whether a point-in-time export is accepted or a dated history is expected, and which apps the flows cover
Enrolled credential inventory per user	Keycloak user credential data via admin API or reporting; authentik user and authenticator device records	Whether the inventory must show credential type (TOTP, WebAuthn, passkey) and enrollment date per user
WebAuthn or passkey enrollment records	Keycloak WebAuthn registration events and credential records; authentik authenticator stage enrollment entries in audit logs	Whether attestation data is required, and how phishing-resistant authenticators are distinguished from OTP
MFA enforcement tests per application	Test records from your own scripted or manual login tests against each SAML or OIDC client, kept outside the identity provider	Which applications are in scope at each maturity level, and how often tests must be repeated
Privileged account MFA records	Keycloak admin events and role mappings for administrative realms; authentik audit logs showing privileged group membership and login stages	How privileged accounts are defined, and whether MFA must be proven for administrative console access separately
Identity provider audit logs	Keycloak admin events and login events forwarded to a SIEM such as Wazuh; authentik audit log entries forwarded through its event and log outputs	Log retention period, tamper protection, and who reviews the logs and how often
Change records for identity platform upgrades	Upgrade tickets, test results and pre-upgrade database backups; Keycloak release notes and Operator approval mode settings	Whether change approvals, rollback plans and restore tests must be dated and signed
Essential Eight assessment evidence guide cross-references	Mapping from each MFA item to ISM control IDs such as ISM-1504 and ISM-1505, using the assessment evidence guide and ISM OSCAL profiles	Which ISM version and Essential Eight maturity level the assessor will use to score your evidence

What the identity platform alone does not satisfy

A Keycloak or authentik deployment authenticates people, but the Essential Eight covers eight strategies, and MFA only counts where every path into a system goes through the identity provider. The cards below cover the gaps that most often remain after an SSO rollout looks finished.

Endpoint and application hardening

Essential Eight strategies such as application control, user application hardening and restricted Microsoft Office macros act on endpoints, not on the login page. A user who passes phishing-resistant MFA can still run an unapproved binary or a macro-enabled document. Check that these strategies are implemented and that their effectiveness is evidenced on the same device fleet the SSO covers.

Applications that bypass the IdP

Legacy line-of-business applications, local desktop clients and some database tools cannot use SAML or OIDC, so they authenticate with local passwords and sit outside MFA. The Essential Eight MFA controls apply to these systems as well as to online services. Build an inventory of every application, mark the ones that cannot federate, and decide whether each gets a gateway, a privileged access control or a retirement date.

Legacy protocols still enabled

Many directories still accept NTLM, basic authentication or older token flows alongside the new IdP, and a single enabled legacy path lets an attacker skip the MFA prompt entirely. Confirm which protocols each client can reach, disable those that are not needed, and test that the disabled paths fail closed. Record the result as configuration evidence rather than a statement of intent.

Administrator accounts outside the IdP

Local administrator accounts on servers, network devices and hypervisors often hold the most privilege and were never moved to the identity provider. The ML2 and ML3 requirements treat privileged and unprivileged users alike, so each of these accounts needs MFA that is phishing-resistant at ML3. Inventory break-glass and service accounts, document who holds them, and decide which ones require a separate control.

No assessment or evidence process

A working Keycloak or authentik realm does not show maturity on its own. The Essential Eight is assessed against the maturity model through evidence of implementation and effectiveness, and there is no ASD certificate to display. Define who assesses each strategy, which exports (realm configuration, policy settings, enrollment logs) prove the control, and how often the evidence is refreshed after an upgrade.

Eight strategies, not MFA alone

MFA is one of eight mitigation strategies, alongside patching applications, patching operating systems, restricting administrative privileges, application control, restricting Office macros, user application hardening and regular backups. An identity platform supports the MFA and some privilege controls, but patching, backups and application control need their own tooling and owners. Map each strategy to a named owner and a system of record before reporting a maturity level.

Questions buyers ask about Essential Eight MFA and open-source SSO

What drives the cost of an open-source SSO rollout for Essential Eight MFA?

The cost is driven mainly by the number of applications to integrate, the directories to federate, the high availability design, how many staff must enroll MFA, and the support model after go-live. Keycloak and authentik are free to download under Apache-2.0 and MIT for their core code, so most spend goes to infrastructure, the database, integration work, and people. Infrastructure and the database recur every year, while integration, configuration and enrollment are largely one-time. Ask any partner for a quote that separates these items, lists each application with its protocol (SAML, OIDC or none), and states who pays for ongoing patching and upgrades. Some authentik features, such as Microsoft Entra ID integration and mTLS, sit in its paid enterprise tier, so confirm the edition before pricing.

How long does an open-source SSO and MFA project take?

The duration depends on scope, and no fixed timeline applies to every organization. The main variables are how many applications need SSO, whether any legacy systems lack SAML or OIDC support, how many directories must be connected, whether the identity provider runs in a highly available cluster, and how quickly staff can be enrolled in phishing-resistant MFA. Engagements are typically fixed-scope, so DeployOpen agrees the scope, deliverables and timeline in writing before work starts. Ask for a phased plan that starts with a pilot application group, then extends in stages, and confirm the dependencies on your change windows and assessor availability.

What does our team need to provide before an SSO engagement starts?

Your team needs to supply an application inventory, named business and technical owners for each system, the directories and identity sources to federate, and the current MFA and session policies. You should also name an administrator owner for the identity provider, a contact for the assessor who will review the evidence, and the change approval path. For each application, record the protocol it supports, its user population, whether it holds sensitive data, and whether privileged users access it. Missing owners and an incomplete inventory are the most common causes of delay, so settle them before scoping.

Can our internal team implement Keycloak or authentik for Essential Eight MFA?

A capable internal team can run these platforms, but the work requires skills in identity protocols, database operations, high availability, and secure configuration. Keycloak documents three high availability architectures, and each supported design needs a synchronously replicated database. Keycloak also recommends manual approval mode for operator updates, and its minor releases can introduce opt-in breaking changes, so upgrades need testing. authentik no longer uses Redis since its 2025.10 release, so its database carries more load. Assess your staff against these tasks, decide who owns patching and monitoring, and consider a partner for the initial build, hardening and evidence preparation.

Is there an Essential Eight certificate we can obtain?

No. The Essential Eight is a set of mitigation strategies, not a certification scheme, and ASD does not issue a certificate for it. Maturity is evidenced through an assessment of each strategy's implementation and effectiveness against the Essential Eight Maturity Model, which defines Maturity Levels Zero to Three. For MFA, the evidence comes from the controls in the Information Security Manual mapped to each maturity level. DeployOpen prepares the systems, configurations and evidence for that assessment, but it does not issue audit reports or certifications. Ask your assessor which evidence they accept, such as configuration exports and enrollment reports.

Do passkeys satisfy ML3 MFA for every user type?

Passkeys can meet the phishing-resistant requirement at ML3, but they do not cover every user type automatically. At ML3, MFA for human users of data repositories must be phishing-resistant, and MFA for customers must be phishing-resistant, according to ISM controls ISM-1505, ISM-1894 and ISM-1874. Keycloak and authentik support WebAuthn and passkeys, but you must confirm that each user population, including privileged administrators, shared workstation users and any applications that cannot accept the chosen authenticator, has a compliant method. Fallback methods, recovery flows and legacy applications need explicit design and assessor review before you rely on this answer.

How DeployOpen scopes, delivers and supports Essential Eight SSO

DeployOpen plans, implements, hardens, documents and supports self-hosted open-source identity platforms inside the client's own infrastructure. For Essential Eight MFA, we start from the ML level the organization is targeting, map each in-scope system and user group to the controls it must meet, and then build the Keycloak or authentik configuration that proves it.

How we scope

Engagements are fixed-scope, with the systems, user groups and ML level agreed in writing before work starts.
The written scope lists which applications, privileged accounts and online services must authenticate with MFA, and which must use phishing-resistant methods.
We confirm with you which Essential Eight maturity level is the target and which assessor will review the evidence.

How we build

We configure the identity provider, including WebAuthn or passkey authentication flows, MFA enrollment and fallback methods for each user population.
We integrate in-scope applications over SAML or OIDC and test each one for MFA enforcement, including privileged and unprivileged logins.
We run upgrade and failover tests in a non-production environment before any change reaches production.

How we hand over

We document the authentication policy, realm or tenant settings and exported configuration so an assessor can trace each control to a setting.
We deliver runbooks for enrollment, lost-device recovery, administrator access and identity provider outage handling.
We train your administrators on the platform and agree which evidence artifacts you will retain for each ISM control in scope.

How we support

Ongoing support, upgrades and continuous testing are available as retainers, scoped separately from the build.
Security releases of the chosen platform are reviewed against your configuration and scheduled into a tested change window.
Re-testing of MFA enforcement is included in the retainer scope when your assessment cycle or the applications change.

Open source SSO for Essential Eight multi-factor authentication