Does FreeIPA help meet Essential Eight multi-factor authentication?
FreeIPA helps meet the multi-factor authentication strategy for Linux systems, but it does not cover every MFA control in the Essential Eight profiles. ASD's Information Security Manual (ISM) v2026.09.4 Essential Eight profiles contain 46 controls at Maturity Level One (ML1), 87 at ML2 and 123 at ML3, and every ML1 control also appears at ML2. The seven MFA controls tagged ML1 are ISM-1504, ISM-1679, ISM-1680, ISM-1892, ISM-1893, ISM-1681 and ISM-1401. Six of those seven address online services and customers, so the ML1 scope for a Linux estate is narrower than the control list suggests. Read the full set in the ISM OSCAL catalog before you decide which controls your server estate must meet.
The part FreeIPA addresses directly is authentication to systems. ML2 adds ISM-0974 and ISM-1173, which require MFA for both privileged and unprivileged users of systems, not only users of online services. FreeIPA's OTP support (HOTP under RFC 4226 and TOTP under RFC 6238, with software or hardware tokens) can supply the second factor, and it can proxy checks to an existing RADIUS server. ISM-1401 accepts a second factor that is something you have, unlocked by something you know or are, which fits a password plus an OTP or smart card. The harder requirement is ISM-1682, which requires phishing-resistant MFA for system users at ML2. HOTP and TOTP codes can be phished, so confirm with your FreeIPA version whether smart card or passkey authentication meets that bar for each login path, and test it on privileged sudo and SSH access first.
Several controls sit outside FreeIPA. Online services that process sensitive data (ISM-1504, ISM-1679, ISM-1892 and ISM-1893) need federation with a web identity provider, and customer-facing services (ISM-1681 and ISM-1873) need a customer identity system. Confirm that central logging forwards successful and unsuccessful MFA events from FreeIPA to your log platform, as ISM-1683 requires at ML2. Keep in mind that the Essential Eight is a set of mitigations and has no ASD certificate. Maturity is shown through assessment of each strategy's implementation and effectiveness against the Essential Eight maturity model. Build a control-by-control evidence map that names FreeIPA for system logins and another system for everything else.
Mapping ISM MFA controls to FreeIPA capabilities and configuration
This table maps the ISM MFA controls that apply to human access, grouped where they share a requirement, to the FreeIPA capabilities that meet them and the configuration each depends on. Read the coverage column as a planning signal: covered rows still need configuration and evidence, partial rows need a second control or platform, and out-of-scope rows belong to a different identity system. The main takeaway is that FreeIPA can carry most workforce and privileged Linux login requirements, but phishing-resistant MFA and online services need additional design.
| Control | Requirement (paraphrased) | FreeIPA capability and configuration | Coverage |
|---|---|---|---|
| ISM-1504, ISM-1679 (ML1) | MFA for staff access to the organisation's own and third-party services holding sensitive data. | OTP through Kerberos pre-authentication for Linux and Kerberos-aware services. Third-party web apps need federation, for example through Keycloak. | Partial |
| ISM-1680 (ML1) | MFA for third-party services holding non-sensitive data, where the service offers it. | Depends on the provider supporting federation or Kerberos. Confirm each service's options before scoping. | Partial |
| ISM-1173, ISM-0974 (ML2) | MFA for privileged and unprivileged human users of systems, not only online services. | Enable OTP or smart card in PAM and SSSD for SSH and console logins. Set per-host policy and test sudo users. | Covered, if every login path uses PAM |
| ISM-1892, ISM-1893 (ML1) | MFA for staff to the organisation's and third-party customer services holding sensitive customer data. | FreeIPA is a workforce identity store for Linux estates. Customer-facing services need a separate identity platform. | Out of scope |
| ISM-1681 (ML1) | MFA for customers using online customer services holding sensitive customer data. | Not a FreeIPA use case. Customer identity needs a dedicated platform, planned separately. | Out of scope |
| ISM-1401 (ML1) | MFA combines something held with something known, or a held factor unlocked by knowledge or biometrics. | A password plus an OTP token meets the combination. Smart cards need a PIN. Confirm passkey support in your FreeIPA release. | Covered |
| ISM-1872, ISM-1682 (ML2) | MFA for human users of online services and systems must be phishing-resistant. | HOTP and TOTP are not phishing-resistant. Smart cards with Dogtag-issued certificates are the candidate, with certificate mapping configured. | Partial |
| ISM-1873 (ML2, replaced at ML3) | Online customer services offer customers a phishing-resistant MFA option. | Outside FreeIPA's workforce scope. Use a customer identity platform that supports phishing-resistant factors. | Out of scope |
| ISM-1683 (ML2) | Successful and unsuccessful MFA events are centrally logged. | Export FreeIPA and SSSD authentication logs to your central log platform. Confirm which OTP and failure events appear. | Partial |
How privileged and standard Linux users are enrolled for MFA
Privileged administrators are the group Essential Eight most directly targets, because the MFA controls require both privileged and unprivileged human users of systems to authenticate with MFA, and the phishing-resistant requirement is higher at the upper maturity levels. In FreeIPA, administrators are usually members of a dedicated group that sudo rules and HBAC rules reference, so the enrollment decision is made once at the group level and then applied to each host. Confirm with your assessor which privileged paths you must cover, including root access over SSH, sudo to root and any console access.
- Group-based enrollment: Place administrators in a dedicated group and reference that group in sudo and HBAC rules, so access to a host requires the same second factor for every administrator.
- Token assignment per user: Register each administrator's OTP token to their own account. Shared tokens or shared accounts break individual accountability and the logging requirement.
- Host-scoped rules: Bind sudo and HBAC rules to specific host groups, so production hosts can require MFA while lower-risk hosts follow a different policy.
- Root over SSH: Decide whether direct root login is permitted at all. Disabling it and requiring a named administrator to elevate is easier to evidence than enforcing MFA on root.
- Phishing-resistant options: OTP codes are not phishing-resistant on their own. Plan smart card or passkey enrollment for administrators if your target maturity level requires it.
Check that every privileged path on every host produces a logged MFA event, both successful and failed.
Standard staff who log in to Linux systems, whether through SSH or a desktop session, also fall under the MFA controls for systems, not only for online services. Because they usually have no sudo rights, the enforcement point is the HBAC rule that governs who may log in to each host. The enrollment work is mostly about token distribution, self-service recovery and making sure the MFA prompt appears consistently on the access paths staff actually use.
- Per-user OTP tokens: Issue each staff member a software or hardware OTP token bound to their FreeIPA account, using HOTP or TOTP as your design requires.
- HBAC for interactive logins: Restrict login to the hosts and services each role needs, and make sure those rules are the ones that carry the MFA requirement.
- Hardware token logistics: Plan who issues, replaces and revokes hardware tokens. Lost token handling is a recurring operational task, not a one-time setup.
- Recovery and reset: Document how a staff member re-enrolls a token after loss, and who approves the change. Auditors often sample these events.
- Remote access paths: Confirm that VPN, remote desktop and any jump host also trigger the same MFA policy, not only direct SSH.
Confirm with a sample of standard users that each login path they use prompts for the second factor and that a failed attempt is logged.
Service accounts run scheduled jobs, application processes and automation. They are not human users, so the MFA controls aimed at human users do not apply to them, and forcing an OTP prompt into a non-interactive process will simply stop the process. The control design question is how to keep these accounts out of interactive MFA flows while still making sure no person can use them to log in interactively. Confirm the exact scope with your assessor, because the classification of an account determines whether it is in or out of scope.
- Separate account type: Keep service accounts as distinct FreeIPA identities that are not members of the administrator or staff groups used for interactive policy.
- Restricted HBAC: Limit each service account to the hosts and services it needs, and do not allow interactive shell logins for it.
- Non-interactive authentication: Use keytabs, certificates or other non-interactive credentials for automated access, and store them under your secrets controls rather than in personal accounts.
- Named ownership: Record an accountable human owner for each service account, so the inventory can be reviewed and reconciled with the MFA scope.
- Exception evidence: Document why each service account is excluded from MFA and show the HBAC restriction that prevents interactive use.
Review the service account inventory against your group membership and HBAC rules before each assessment, since drift is common when new automation is added.
Why OTP alone may not satisfy the phishing-resistant requirement
ISM-1872 and ISM-1682 require phishing-resistant MFA for human users, and a one-time code typed into a login form can be relayed by an attacker. The cards below separate what OTP does well from the options FreeIPA supports that are designed to resist relay, and what to confirm before you rely on any of them.
What HOTP and TOTP prove
HOTP (RFC 4226) and TOTP (RFC 6238) tokens give the something-you-have factor in FreeIPA, and the code is combined with a password. The weakness is that the user types a valid code into whatever page asks for it. A convincing lookalike login can capture the password and code and replay them within the validity window, so OTP counts as MFA but not as phishing-resistant.
Why OTP fails the phishing test
A phishing-resistant method binds the authentication to the server or origin the user is really connecting to, so a relayed answer is useless. Typed codes do not have that binding. For Essential Eight assessments, treat OTP as meeting the MFA requirement at the lower maturity levels, and plan a separate phishing-resistant option for human users of systems and online services at the higher levels.
Smart cards with certificate mapping
Smart cards hold a private key that never leaves the card, and the Kerberos login depends on a certificate that FreeIPA maps to a user identity. This is a strong option for privileged administrators on Linux hosts. Confirm with your FreeIPA version and the client OS which smart card and certificate mapping settings are supported, and test the full login path, including SSH and console access.
Passkeys as a phishing-resistant factor
Passkeys bind a key pair to the relying party, so a fake site cannot receive a usable response. Passkey support in FreeIPA is recent and changes between 4.x releases, so confirm the exact supported flows, authenticator types and client OS behavior against the release you plan to deploy. Test enrollment, recovery and loss of a device before any user depends on it.
Confirm support before you commit
Do not assume a method works on every Linux client. Check the FreeIPA release notes for the version in your estate, the SSSD and PAM stack on each client OS, and whether a given login path such as SSH, sudo, a web console or a desktop uses Kerberos or a password fallback. Record the result per path, because an unphishable factor that a weaker fallback can bypass does not satisfy the requirement.
Evidence for an assessor
Record which factor each user group uses, which login paths accept only phishing-resistant factors, and the central logs of successful and unsuccessful MFA events that ISM-1683 requires. Keep the mapping of each login path to its control, and show that OTP is not the sole route for privileged or online service access. An assessor will test the actual paths, not the design document.
Configuration sequence for Essential Eight MFA on FreeIPA
This sequence turns an Essential Eight MFA target into a FreeIPA configuration that covers privileged access first, produces enrolled authenticators and access rules that match the scope, and leaves a central log and evidence trail an assessor can follow.
Confirm target maturity level and in-scope systems
Before any FreeIPA change, the organization decides which Essential Eight maturity level it is working toward and lists the Linux servers, services and online customer-facing systems in scope. The ASD Information Security Manual publishes Essential Eight ML1, ML2 and ML3 baseline profiles in OSCAL, and the MFA controls differ by level, so the team should map each in-scope system to the controls it must meet. Ask your assessor or your ASD adviser which profile applies to your environment. Done means a signed scope register that names each system, its data sensitivity, its privileged accounts and the ISM control IDs that apply to it.
Deploy FreeIPA replicas per the recommendations
Build the FreeIPA server topology before enforcing MFA, because authentication policy is only as reliable as the servers that enforce it. The FreeIPA deployment recommendations advise at least two to three replicas in each datacenter, no more than four replication agreements per replica, dedicated servers without other applications, and at least one replica per datacenter running PKI or DNS if those services are used. Your platform or identity team does this work, usually with a partner, on infrastructure you control. Done means replication is healthy between all servers, and a backup has been taken and restore-tested on a non-production copy.
Enforce OTP or smart card policy for privileged groups first
Start enforcement with the groups that hold administrative rights, such as sudo-capable administrators and service owners, because ISM controls for privileged users apply at every level and carry the strictest phishing-resistance expectations. Decide which second factor each group uses: FreeIPA supports HOTP and TOTP tokens, including hardware tokens such as YubiKeys, and smart card certificate mapping is documented separately. Passkeys and phishing-resistant options must be confirmed against the FreeIPA release you run, as they depend on version. Done means a test administrator can sign in with the new factor and a user without it is refused.
Enroll tokens and verify each factor
Enroll authenticators to each privileged user and record every token in the identity store so that it can be traced to one person. Hardware tokens should be issued through a controlled process, with the serial and owner recorded, and software tokens should be bound to a named account. Confirm that the Kerberos settings MFA depends on are in place, including ticket lifetimes and the authentication indicators your release supports. Done means every privileged account has at least one verified factor, lost or retired tokens can be disabled, and a sample of logins proves the second factor is required.
Configure HBAC and sudo so MFA applies where required
Use host-based access control and sudo rules to define where each account can log in and what elevated actions it can take, then align those rules with the MFA scope from step one. An account with access to a system in scope should not reach it through a path that skips the second factor, so review SSH, console and service access paths individually. Note that MFA enforcement in FreeIPA depends on how each service authenticates, so confirm every path, including those that use SSSD on clients. Done means a test matrix shows each in-scope path requires the required factor and each out-of-scope path is documented.
Send MFA success and failure events to central logging
The ISM requires successful and unsuccessful MFA events to be logged centrally, so forward FreeIPA authentication events, Kerberos and OTP validation results, and SSSD client logs to your log platform before you rely on the configuration. Set retention and access controls on that store and confirm that a failed attempt on a privileged account generates an alert your team reviews. Test by generating a success and a failure on a test account and finding both in the central store. Done means both event types are searchable centrally with timestamps, account names and host names.
Document the evidence trail and assessment handover
Write down, for each in-scope system, the ISM control IDs it meets, the configuration that meets them, the token and policy records that prove it, and the log query that shows it working. Keep configuration exports, change records and a dated copy of the scope register together so an assessor can trace a control to a setting and to an event. Be clear about what this evidence does not cover: the Essential Eight is a set of mitigations assessed against the maturity model, with no ASD certificate, so the assessor decides maturity and the organization supplies the proof. Done means an independent reviewer can follow one privileged login from policy, to token, to log event without help from the implementer.
What evidence FreeIPA produces for an Essential Eight assessment
An Essential Eight assessment looks at how the MFA strategy is implemented and whether it works in practice, so the evidence has to show configuration, activity and recovery over time. The cards below cover the artifacts FreeIPA can produce and the ISM controls each one supports.
Token and policy configuration exports
Export the OTP token inventory and the password and authentication policy settings that apply to users and privileged groups. Assessors use these to confirm that MFA is enforced for the accounts in scope, not just available. Record who enrolled each token and when, and check that the export matches what the live server returns. Map the export to ISM-1173 and ISM-0974, which cover privileged and unprivileged human users of systems.
Sudo and HBAC rule definitions
Export the host-based access control rules and sudo rules that decide who can reach a server and what they can run after login. These show which privileged paths require a second factor, if your design ties them to MFA-backed services. Keep dated copies so you can show the rule set in force during a given assessment period. Compare them with the group membership exports to confirm that privileged roles are not granted by accident.
Central authentication logs
Forward successful and failed authentication events from the FreeIPA servers and the Kerberos KDC to a central log platform. ISM-1683 expects both successful and unsuccessful MFA events to be centrally logged, so the log pipeline is evidence in its own right. Test that a failed OTP attempt on a sample host appears in the central platform with a timestamp and account name. Confirm retention with your log platform owner, because FreeIPA does not set that period for you.
Backup and restore records
Keep the output of each ipa-backup run and the records of periodic restore tests. The backup documentation warns that restoring an outdated backup into an active replica topology can break replication, so a restore test should be done in an isolated environment and logged. Record which server holds certificate renewal and CRL publication, because that role is also part of recovery evidence. Tie these records to the regular backup strategy in the Essential Eight.
Change records for identity configuration
Keep a dated record of every change to MFA settings, OTP tokens, sudo and HBAC rules and server topology. Assessors look for evidence that changes were approved, made and checked, which helps show that the MFA controls stayed in place between assessments. Store the change tickets next to the exports they produced so the before and after states can be compared. Confirm with your change board which changes need a second approver.
Assessment evidence mapped to ISM controls
Assessors judge implementation and effectiveness against the maturity model, and the Essential Eight is not a certification with a certificate to show. Build a control map that links each artifact above to the ISM controls it supports, such as ISM-1504, ISM-1872 and ISM-1683. Review the map whenever the ISM OSCAL catalog changes, and keep older versions for evidence covering earlier periods.
Questions buyers ask before hiring help with Essential Eight MFA on FreeIPA
What drives the cost of an Essential Eight MFA project on FreeIPA?
The main drivers are the number of hosts that need MFA, the number of FreeIPA servers and replicas, the token types you choose, and how many online services sit in scope. Hosts and services multiply the configuration and testing work, while each token type (OTP, smart cards, passkeys) adds its own enrollment, policy and support steps. Costs have a one-time part (design, build, testing, documentation) and a recurring part (token lifecycle, upgrades, evidence refresh). Ask any provider for a quote that lists each host group, token type and online service separately, with the deliverables for each.
How long does Essential Eight MFA work on FreeIPA take?
No duration has been established for this work, so treat any timeline as something to confirm in writing. The main drivers are the same as for cost: the number of hosts and online services, whether you already run FreeIPA or are installing it, the token types in use, and how many privileged and unprivileged user groups need different rules. Existing environments with clean identity data and documented access usually move faster than estates that still rely on local accounts or shared credentials. Ask for the build sequence and the milestones, and check which of them depend on your change windows or approvals.
What does the work need from our team?
The work needs named people who can make decisions and provide access. Expect to supply an owner for identity policy, an owner for each host group and online service in scope, network access to the FreeIPA servers, and someone who can approve changes to privileged access. Your security or compliance lead should confirm which Essential Eight maturity level you target and which controls the evidence must cover. You will also need a way to receive and store tokens or smart cards, and a central log destination that captures successful and unsuccessful MFA events.
Can our internal team implement Essential Eight MFA on FreeIPA alone?
Yes, an internal team can do this if it has FreeIPA, Kerberos, SSSD and PKI skills and time for design, testing and evidence. FreeIPA is open source, so the software itself is available to any team. The harder parts are usually the ones outside the product: mapping each in-scope system to an Essential Eight control, deciding how privileged and unprivileged users are separated, testing lockout and recovery paths, and producing evidence an assessor can examine. Many teams split the work, keeping day-to-day operations in-house and bringing in outside help for design review, the initial build or an assessment-readiness check.
Is FreeIPA free to license for MFA?
FreeIPA is licensed under GPL-3.0-or-later and is a community project with no paid edition of its own, so there is no license fee for the software. Costs come from the infrastructure you run it on, the staff time to design and operate it, and any outside services you choose to buy. Check the license terms of any other component you add, such as a RADIUS server, smart card middleware or a hardware token vendor's tooling, because those may carry their own conditions.
What remains our responsibility after the implementation?
Several parts stay with your organization even when a partner builds the system. You own the policy decisions about who must use MFA, which token types each group gets, and how exceptions are approved. You also own token issuance, loss and replacement, user off-boarding, the ongoing review of privileged access, patching and upgrades of FreeIPA servers, backup testing, and the retention of MFA logs. Essential Eight is a set of mitigations, not a certification, so no body issues an Essential Eight certificate. Maturity is shown through an assessment of how each strategy is implemented and how well it works, and that assessment is your responsibility to arrange and to answer.
Where does FreeIPA alone fall short for Essential Eight MFA?
FreeIPA covers OTP and certificate-based authentication for Linux estates, but it does not, by itself, meet every requirement. Phishing-resistant MFA for privileged and unprivileged human users needs careful choice of token type, and passkey or smart card support must be confirmed for your release. Authentication to third-party online services and customer-facing services often sits outside FreeIPA and needs its own MFA design. Central logging of MFA events, the operational processes around them, and the evidence of effectiveness are also outside the product. Confirm each gap against the current ASD maturity model before you commit to a design.
How DeployOpen scopes and delivers Essential Eight MFA configuration
DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure, so FreeIPA multi-factor authentication is configured on servers you control. We start from the Essential Eight MFA requirements you must meet, then agree a fixed scope in writing before any build work begins.
How we scope
- Inventory which Linux hosts, privileged accounts and online services fall under the MFA requirements at your target maturity level.
- Agree in writing which authenticators apply to each group, such as OTP, smart cards or passkeys, and which systems remain out of scope.
- Confirm with your assessor or internal audit which evidence they will expect, and record any gaps FreeIPA cannot close alone.
How we build
- Configure FreeIPA OTP and Kerberos settings for privileged and unprivileged users in a non-production replica first.
- Test each authentication path, including SSH, console and sudo, with failed and successful events confirmed in your central log store.
- Document the topology, enrollment steps and token issuance process so your team can repeat the build on its own servers.
How we hand over
- Deliver the written configuration record, test results and runbooks for token enrollment, reset and revocation.
- Walk your operations and security staff through the lockout, recovery and privileged access procedures before sign-off.
- List the controls that depend on processes, third-party services or an external assessment, so your team owns those items after handover.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after the fixed-scope work ends.
- Plan FreeIPA upgrades and security releases against your authentication configuration and retest the MFA paths afterward.
- Review changes to your Essential Eight baseline profile and adjust the FreeIPA configuration and evidence when your target level changes.
