How FreeIPA helps meet NIST SP 800-53 IA-2 and IA-5 on Linux estates
If you own a federal or FISMA-aligned system and need IA-2 and IA-5 evidence for Linux access, FreeIPA supplies identity, authentication and policy mechanisms, but your organization must define the authenticator processes, and the assessor decides whether the result is sufficient. FreeIPA gives you one directory of users, groups and hosts, a Kerberos KDC for single sign-on, OTP tokens and password policy, which is where most IA-2 and IA-5 technical work lands. Those mechanisms do not make a control implemented on their own.
On the FreeIPA side, IA-2 maps to unique user identities in the directory, Kerberos and OTP for multi-factor authentication to Linux accounts, and smart card or certificate mapping where you need PIV-style credentials. IA-5 maps to password quality and lifetime settings, OTP token enrollment and revocation, and host and service keytabs. The organization owns identity proofing before an account is created, lifecycle procedures for lost, compromised and revoked authenticators, rules for shared group accounts, and the refresh schedule. Confirm each control's enhancements against your own baseline before you scope the build.
Confirm which baseline applies to your system. SP 800-53B selects IA-2 and IA-5 for the low, moderate and high baselines, and it selects different enhancements at each level, such as IA-2(5) at the high baseline only. Choose your impact level and tailoring with your authorizing official, and ask your assessor which evidence they expect for each selected enhancement. A FreeIPA configuration that matches a control is a starting point, not an assessment outcome.
Mapping IA-2 and IA-5 requirements to FreeIPA features and configuration
This table pairs each IA-2 and IA-5 requirement selected in the SP 800-53B baselines with the FreeIPA capability that addresses it and the configuration needed. Read each row as a starting point for your control narrative: where a row says to confirm, check the documentation for the release you install before you write the control as implemented.
| Requirement | FreeIPA capability | Configuration needed |
|---|---|---|
| IA-2: Unique identification and association with processes acting for users | Kerberos principals in the MIT Kerberos KDC with 389 Directory Server user objects, giving each person a single identity for SSO | Create one account per person, disable shared logins, and confirm that sudo and service actions log the acting principal |
| IA-2(1): MFA to privileged accounts | OTP tokens (HOTP per RFC 4226, TOTP per RFC 6238) enforced through Kerberos pre-authentication, with RADIUS proxying to an existing server if you have one | Enable OTP for administrator groups, enroll hardware or software tokens, and confirm the Kerberos settings that require OTP for those accounts |
| IA-2(2): MFA to non-privileged accounts | The same OTP mechanism applied to standard user groups, or smart card and certificate-based login where the organization issues PIV or similar credentials | Set MFA scope by group, document which non-privileged accounts are in scope, and confirm how SSH and console logins apply the second factor |
| IA-2(8): Replay-resistant access to accounts | Kerberos ticket-based authentication with time-limited tickets; OTP codes are single-use within their validity window | Confirm with the vendor documentation for your release how replay is prevented for each login path, including SSH and web access |
| IA-2(12): Acceptance of PIV credentials | Smart card login with certificate mapping, using certificates issued by the integrated Dogtag CA or by an external CA you trust | Load trusted CA certificates, configure certificate mapping rules, and test with each PIV card type your agency accepts. Mapping is partial until the PIV chain is validated in your environment |
| IA-2(5): Individual authentication with group authentication (high baseline only) | Individual Kerberos identities layered on shared group access through HBAC and sudo rules | Keep group accounts out of login paths, require each member to authenticate individually, and confirm that group membership changes are logged. Confirm the exact behavior for your configuration |
| IA-5(1): Password-based authentication | Password policies per group in 389 Directory Server, with Kerberos enforcing expiration and lockout settings | Set minimum length, complexity, history, expiration and lockout values in the password policy, and record the values as evidence |
| IA-5(2): Public key-based authentication | Dogtag-issued certificates for hosts and services, and smart card public keys mapped to users | Define certificate profiles, key lengths and renewal, and confirm where private keys are stored. Confirm the supported algorithms for your release |
| IA-5(6): Protection of authenticators | Kerberos keys stored in the directory and protected by FreeIPA server access controls; OTP seeds held by the server | Restrict read access to directory and CA data, protect backups, and confirm where OTP secrets are stored and how they are exported or revoked |
| IA-5 lifecycle: Initial distribution, loss, revocation and change of defaults | Account provisioning, token enrollment, token revocation, password reset and disabling of accounts in the central directory | Write procedures for identity proofing before enrollment, token replacement after loss, and removal on termination. Ensure default passwords are changed before first use |
Evidence FreeIPA produces for an IA-2 and IA-5 assessment
An IA-2 and IA-5 assessment turns on whether the identity records, policy settings and authenticator lifecycle can be shown as they were on a given date. The cards below cover the artifacts FreeIPA can export and the questions an assessor will ask of each, using the examine, interview and test methods described in SP 800-53A.
Policy export and password settings
Export the global password policy and every group password policy with ipa pwpolicy-show and ipa pwpolicy-find, then save the output as a dated file. An assessor will examine minimum length, history, lockout thresholds and failure windows against the organization's own IA-5(1) requirement, and will test whether a sample account inherits the expected policy. Confirm that the export shows effective values for each group, not only the default. Compare every export with the change record that approved it.
User and group inventories
Produce a dated export of users, groups and their UIDs with ipa user-find --all and ipa group-find --all. Assessors use this to confirm that each organizational user has a unique identifier, that no shared or generic accounts exist without a documented group authenticator process, and that disabled or stale accounts are tracked. Interview the account owners for a sample of entries to confirm that the record matches the person who uses the account.
OTP token records and enrollment
Export token inventories with ipa otptoken-find to show token type, owner, creation date and status for HOTP and TOTP tokens. Assessors examine whether the MFA population matches the privileged and non-privileged account lists used in IA-2(1) and IA-2(2), and test a sample login to confirm that a second factor is required. Record how revoked or lost tokens were disabled, since IA-5 expects prompt handling of lost and compromised authenticators.
Certificate inventory from the Dogtag CA
List issued certificates with ipa cert-find and keep the output with the profile names, subjects, expiration dates and revocation status. For IA-5(2) public key-based authentication, an assessor will examine whether certificates used for login are current, traceable to a named owner and revoked when a device or person leaves. Check the CRL and renewal history on the first server, since that server handles renewal and CRL publication by default.
Backup and restore records
Keep the output and logs from each ipa-backup run, noting whether it was a full or data-only backup, the server, the time and the storage location. Assessors use these records to test whether authenticator and identity data can be recovered without losing revocations or policy state. Document a restore test in a non-production environment, and note that restoring an outdated backup into an active replica topology can break replication.
Change logs under change control
Store every export, the audit log extracts and the change tickets together in a versioned evidence repository with a retention rule set by your policy. Assessors interview administrators to confirm who can change policy, tokens and certificates, then compare those answers with the logs. Each dated export should be signed or hashed and linked to the ticket that authorized the change, so the sample an assessor selects can be traced from start to finish.
Configuration decisions that shape the IA-5 story
The IA-5 story is decided by a handful of FreeIPA configuration choices made before the first user logs in. IA-5 asks the organization to set authenticator strength, handle lost or compromised authenticators, change defaults before first use and control group authenticators. In FreeIPA, the password policy, OTP enforcement, sudo and HBAC rules and group membership model are where those requirements become settings an assessor can sample. Decide the password policy values (minimum length, character classes, maximum lifetime, history and lockout) per group or per role, not only through the global policy, and record the rationale for each value so that the policy can be traced back to the control.
Decide which accounts must present an OTP token. Privileged accounts and any account that reaches sudo or sensitive hosts are the usual starting set, and the IA-2(1) and IA-2(2) requirements apply to both privileged and non-privileged access. Enforcement is set per user and per authentication path, so confirm for your release how OTP is required for SSH, console and Kerberos logins, and test each path. Token enrollment is an authenticator distribution step: define who verifies identity before a token is issued, who can reset a token and how a lost or revoked token is disabled. Under IA-5, that process needs its own written procedure and records. Restrict sudo and HBAC rules to named groups so that privileged access traces to individual identities rather than to shared accounts.
Shared and group accounts are the usual gap. Where a service or break-glass account must exist, keep its authenticator in a vault, limit who can retrieve it, and change it when membership of the group changes, as IA-5 requires for group authenticators. Review the defaults of your release before rollout, because FreeIPA features and default values change across 4.x releases; confirm each setting against the version you run, and document the version in the evidence pack. Note also that FreeIPA prepares these controls and their evidence, but an independent assessor determines whether they satisfy IA-5.
Configuration sequence for IA-2 and IA-5 readiness
This sequence turns FreeIPA into an identification and authentication layer that an assessor can trace, from the system boundary through to test evidence for each IA-2 and IA-5 requirement. Each step closes with an output that feeds the next one.
Define the system boundary and control baseline
The compliance lead and system owner list every Linux host, service account and application that falls inside the assessed system, then record which SP 800-53B baseline (low, moderate or high) the system is categorized against. This determines which IA-2 and IA-5 enhancements apply, such as IA-2(1), IA-2(2) and IA-5(2) at the moderate and high levels. The step is done when the boundary and baseline are approved in writing and the in-scope population is exported as a list the identity team can enroll against.
Confirm server topology and backup posture
The platform team checks that the FreeIPA server layout matches the deployment recommendations for replicas per datacenter, replication agreements and dedicated servers, and confirms that ipa-backup runs on a schedule with restores tested in a non-production copy. Assessors will ask who owns certificate renewal and CRL publication on the first server, so that ownership is written down. The step closes when the topology diagram, backup schedule and a successful restore record are filed with the control evidence.
Set password and lockout policy
The identity administrator configures the global and group password policies in FreeIPA, covering minimum length, complexity, history, expiration and account lockout thresholds, and aligns them with the organization's IA-5(1) requirements for password-based authentication. Initial passwords for new accounts and reset flows are set so that defaults are changed before first use. The step is complete when an exported policy file and a test account showing the lockout and expiration behavior are attached to the evidence set.
Enroll Linux clients with SSSD
The platform team enrolls each in-scope Linux host as a FreeIPA client, using the same enrollment method across the estate so that SSSD, Kerberos and host identity are configured consistently. Each host is checked for a host keytab, a working SSSD domain and a Kerberos login. Unique user identities are confirmed by logging in as individual users rather than shared accounts, which supports IA-2 unique identification. The step closes with an enrollment inventory that matches the boundary list from the first step.
Enforce OTP or smart card MFA
The identity administrator assigns OTP tokens (HOTP or TOTP) or smart card certificate mapping to privileged and non-privileged users, and sets the Kerberos and PAM settings that the chosen MFA method depends on. Where an existing RADIUS server holds the OTP check, the team confirms the proxy path and fallback behavior. Token enrollment and revocation steps are written as procedures. The step is done when a test login is shown to require the second factor for each population, with the authentication records kept as evidence.
Restrict access with HBAC and sudo
The identity administrator defines host-based access control rules so that only named groups can log in to each host class, and creates sudo rules that limit privileged commands to the roles that need them. Rules are tested with a user outside the permitted group and with a privileged user performing a permitted task. The step closes when the HBAC and sudo rule exports are saved, and the denied and permitted test results are recorded against the relevant user populations.
Document authenticator lifecycle procedures
The security team writes procedures for the authenticator events that IA-5 addresses: identity verification at initial distribution, handling of lost, compromised and revoked authenticators, scheduled or event-driven refresh, and membership changes for any shared or group account. Each procedure names the FreeIPA action, the approver and the record kept. The step is complete when the procedures are approved and linked from the control narrative, so that each lifecycle event can be traced to a FreeIPA change log entry.
Capture test evidence for each control
The assessment lead runs a dated test set against the configured environment, covering unique identification, MFA for each population, password and lockout behavior, HBAC and sudo denials, and one lifecycle event such as token revocation. Results are mapped to the control identifiers and to the assessment procedures in SP 800-53A, with the methods used (examine, interview or test) noted. The step closes when a named owner signs off the evidence package and the gaps are logged for remediation before the independent assessor reviews the system.
Where FreeIPA stops and your program has to take over
FedRAMP applies to cloud products and services that create, collect, process, store or maintain federal information on behalf of an agency. A system used only for one agency's own operations on cloud infrastructure, and not offered as a shared service, falls outside that scope under the M-24-15 scope rules. Whether FreeIPA sits inside or outside FedRAMP therefore depends on how the service is offered, not on the software alone. A FreeIPA deployment run by an agency for its own staff is usually assessed under FISMA and SP 800-53 instead. A provider that offers an identity service to several agencies or customers must confirm its scope with its authorizing official and assessor.
- Shared service test: Confirm whether the identity service is offered to more than one agency or customer, since that is the point where FedRAMP scope usually applies.
- Inherited controls: A cloud host or managed platform may supply some IA-2 and IA-5 controls, which must be mapped in the system security plan.
- Authenticator content: Password and OTP policy are configured in FreeIPA, but the provider still has to document how users are issued and recover tokens.
- Boundary documents: Network diagrams must show every FreeIPA replica, DNS server and backup location inside the authorization boundary.
- Third-party assessment: An independent assessor, not DeployOpen, decides whether the controls satisfy the baseline.
Confirm the service model and scope decision in writing before designing the identity layer.
For an on-premises federal system, FreeIPA can implement much of the technical side of IA-2 and IA-5: unique Kerberos identities, OTP for multi-factor authentication, smart card and certificate mapping, and password rules. The agency still owns the surrounding program. Under FISMA, Inspectors General assess agency system security independently, and NIST leaves implementation timelines to OMB Circular A-130. The gaps below are where a team most often assumes the software will do work it does not do.
- Identity proofing: FreeIPA does not verify that a person is who they claim to be before an account is created. HR or sponsorship processes must do this and produce records.
- Authenticator issuance policy: Rules for who receives a token, how it is delivered and how loss or compromise is reported must be written by the owner.
- PIV issuance: Issuing PIV credentials is a separate process. FreeIPA can map certificates it trusts, but the credential issuance chain and its policy belong to the agency or its PIV provider.
- Group account rules: Shared accounts and changes in group membership need procedures that FreeIPA will not enforce on its own.
- Assessment evidence: The agency must collect and retain evidence for assessors, and only an independent assessor can reach an authorization decision.
List each IA-5 requirement and name the person or process responsible for the parts FreeIPA does not cover.
Systems that process criminal justice information fall under the FBI CJIS Security Policy, and systems that process controlled unclassified information on non-federal systems fall under 32 CFR 2002.14(h)(2), which points to NIST SP 800-171. Both regimes add requirements beyond the IA-2 and IA-5 controls, and their assessment models differ from SP 800-53. A FreeIPA deployment must be checked against the applicable policy version and the contract or agency rules that apply to it.
- Cryptography requirements: CJIS Security Policy v6.1, which took effect on 26 June 2026, requires FIPS 140-3 validated modules or AES with at least 256-bit keys for CJI outside physically secure locations. Confirm how FreeIPA's cryptographic modules and FIPS mode are configured against that requirement.
- Scanning cadence: The same policy requires vulnerability scanning at least monthly, which is an operational duty the owner must staff and document.
- CMMC cloud rules: Under 32 CFR 170.17(c)(5), a defense contractor storing CUI in a cloud service needs FedRAMP Moderate or equivalent. Confirm this if the identity service is hosted in the cloud.
- Policy versions: Confirm the exact requirement set with the state CJIS systems agency or the contracting authority, since requirements vary by agreement.
- Program ownership: Assign who maintains the policy mapping, the training records and the incident process.
Confirm with your authorizing body which policy version and which cloud or CMMC rules apply before choosing the FreeIPA configuration.
Gaps FreeIPA does not close for IA-2 and IA-5
FreeIPA handles many technical authentication mechanics, but IA-2 and IA-5 also require written procedures, lifecycle decisions and evidence that no directory product supplies. The cards below mark the items your organization must own, and the points to confirm before an assessment.
Identity proofing and registration
IA-5 expects you to verify a person's identity before an authenticator is first issued. FreeIPA records the account and can enforce a first-login password change, but it does not check identity documents or confirm who received a token. Your organization must define the proofing steps, who performs them, and how the approval is recorded and linked to the account created in FreeIPA. Ask your assessor which evidence they expect for registration of privileged and non-privileged users.
Authenticator loss and compromise procedures
IA-5 requires handling of lost, compromised and revoked authenticators. FreeIPA can disable an account, revoke a certificate or remove an OTP token, but the decision to act and the timing belong to your process. Write the reporting channel, the revocation steps for each authenticator type (password, OTP token, smart card, certificate), and the re-issuance checks. Test the procedure with a real token so the steps are proven before an assessor asks.
Group account membership changes
IA-5 requires that shared or group authenticators change when membership changes. FreeIPA can remove a user from a group, but it does not rotate a shared password or re-key a shared credential automatically. Maintain a register of group accounts, their members and the authenticator behind each one. Define who triggers rotation after a departure and how the change is logged, so the removal is traceable to a specific date and approver.
PIV credential issuance
IA-2(12) covers acceptance of PIV credentials, and FreeIPA's smart card support does not by itself make your environment a PIV issuer. Your organization must decide which certificate authority issues PIV-based credentials, how card personalization and identity vetting are handled, and how certificate mapping in FreeIPA matches those credentials to accounts. Confirm the required issuing authority and card profile with your agency or sponsor before design.
FIPS 140 validation of deployed modules
Assessors look for cryptographic modules validated under FIPS 140 when authenticators and sessions are protected. Whether the FreeIPA packages, the OS crypto libraries and the Dogtag components on your platform run in a validated mode is a question for your platform vendor and your own build records, not a claim this page makes. Ask for the validation certificate numbers covering each module in your stack and record how FIPS mode was enabled on every server.
Applications outside Kerberos and SSSD
Many applications authenticate with their own local accounts, API keys or basic logins and never call Kerberos or SSSD. Those accounts sit outside FreeIPA's password policy, lockout and OTP controls. Inventory every application and appliance, classify its login method, and decide whether it moves to FreeIPA-backed sign-in, is placed behind a federated gateway, or is documented as a compensating exception with its own authenticator procedures.
Independent assessment
FreeIPA configuration can be shown to an assessor, but the assessment itself is performed by an independent party such as an assessor or inspector general. DeployOpen prepares systems, controls and evidence for that review. It does not issue audit reports or attestations. Agree the assessment scope, the objects an assessor will examine, and the evidence list early, then confirm the assessor's requirements for the baseline your system is categorized under.
Questions buyers ask about FreeIPA and NIST SP 800-53 IA-2 and IA-5
Does FreeIPA alone satisfy NIST SP 800-53 IA-2 and IA-5?
No. FreeIPA supplies mechanisms, not a compliant control on its own. It gives you unique Kerberos identities, OTP tokens, certificate-based logins and password policy, but IA-2 and IA-5 also require your organization to define who gets an identity, how authenticators are issued, changed, revoked and protected, and how group account authenticators are handled when membership changes. Those decisions and their records sit outside the software. An assessor will test the system as configured and operated, so the policies, procedures and evidence around FreeIPA determine whether the controls are met. Assessment procedures for each control are published in SP 800-53A, which is a useful checklist for what evidence to prepare.
Which NIST baseline applies, and what do the 149, 287 and 370 counts mean?
The baseline follows from the impact level your authorizing official assigns to the system, not from FreeIPA. SP 800-53B defines low, moderate and high baselines. According to NIST's OSCAL profiles for Release 5.2.0, those baselines select 149, 287 and 370 items respectively, counting base controls and enhancements together. Those totals describe the whole control set, so they are not a measure of how much work IA-2 and IA-5 alone involve. For IA-2, the enhancements IA-2(1), IA-2(2), IA-2(8) and IA-2(12) appear in all three baselines, and IA-2(5) appears only in high. For IA-5, IA-5(1) appears in all three, and IA-5(2) and IA-5(6) in moderate and high. Confirm the impact level and tailoring decisions with your system owner and authorizing official.
What drives the effort to meet IA-2 and IA-5 with FreeIPA?
The main drivers are the system boundary, the number of hosts and services that authenticate against FreeIPA, the MFA method you choose, and the state of any existing directory. A boundary that covers a few Linux servers is far smaller than one that includes SSH, databases, web applications and privileged administration paths. Each MFA option has its own enrollment, recovery and support process: OTP tokens, RADIUS proxying to an existing server, and smart cards carry different tasks. Migrating users from an existing LDAP directory or from another FreeIPA deployment adds mapping and validation work. Ask any provider to break effort down by these four factors so you can see which assumptions drive the total.
Can our own team implement FreeIPA controls for IA-2 and IA-5 without a partner?
Often yes, if your team already runs Linux identity, Kerberos and PKI in production and has someone who owns the authenticator policy. The harder part is usually not installation but the governance work: documenting authenticator lifecycle procedures, showing that changes were made under those procedures, and producing evidence on a schedule that an assessor can sample. Replication design, backup handling and the first-server responsibilities for certificate renewal also need experienced operators, because mistakes there can break authentication across the environment. Assess your team's current skills in these areas honestly. A partner is one option for the build, and the decision should rest on your staff's capacity to run and evidence the controls afterward.
What does the work need from our organization?
Expect to supply several roles. Policy owners must agree the authenticator rules, including initial distribution, strength, refresh events and handling of lost or compromised tokens, because IA-5 cannot be satisfied by configuration alone. System owners must confirm the boundary and which hosts and applications are in scope. Your operations team needs change windows for server and client work, and administrative access to the hosts, network paths and any existing directory or RADIUS server involved. Someone must also own the evidence: exports of policy settings, token records, access reviews and change logs. Agree these responsibilities in writing before the build starts so that gaps do not appear during the assessment.
What should a quote for FreeIPA IA-2 and IA-5 work include?
A useful quote is tied to a written scope and lists each deliverable. It should state the systems and hosts in scope, the MFA methods to be configured, the password and authenticator policy settings, the number of FreeIPA servers and replicas to be deployed or changed, the client enrollment approach, and any migration of users or groups. It should name the documents produced, such as authenticator lifecycle procedures and the evidence set, and say what the client must provide. Ask which items are one-time work and which recur, such as support, token administration, upgrades and periodic evidence collection. Also confirm what the provider does not do: DeployOpen, for example, prepares systems and evidence for assessments but does not issue audit reports or certifications.
Which FreeIPA version and features should we check before relying on them for these controls?
Start with the release you plan to run and check its release notes for changes that affect authentication. FreeIPA 4.13.4 fixed two CVEs, including LDAP access control flaws that could let unauthenticated clients obtain credentials, so the currency of your version matters for any assessor who reviews patch status. Confirm MFA behavior against the OTP design documentation, which covers HOTP and TOTP tokens, software and hardware tokens such as YubiKeys, and RADIUS proxying. Verify smart card and certificate mapping for your environment, because those settings depend on your PKI design. Treat the release notes and design pages as the source of truth for each configuration you plan to document.
How DeployOpen scopes and delivers IA-2 and IA-5 configuration and evidence
DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure, including FreeIPA. For IA-2 and IA-5, we turn the control requirements into a written FreeIPA configuration, build it in your environment, and prepare the evidence your assessors will ask for, without issuing any audit report or certification.
How we scope
- Map your in-scope Linux systems, service accounts and privileged users to IA-2 and IA-5 before any configuration starts.
- Agree in writing which control enhancements apply at your impact baseline, such as IA-2(1), IA-2(2) and IA-5(1).
- Confirm the FreeIPA topology, DNS, OTP or smart card needs, and your authenticator lifecycle process as part of the fixed scope.
How we build
- Configure password policy, lockout settings, OTP tokens and smart card mapping in FreeIPA according to the agreed scope.
- Test MFA login paths for privileged and non-privileged accounts, including Kerberos behavior and fallback handling.
- Verify group account handling, default authenticator changes and revocation steps against the written control requirements.
How we hand over
- Deliver configuration records, runbooks and a control-to-configuration mapping that your assessors can trace.
- Document how each authenticator type is issued, refreshed, revoked and protected, with the FreeIPA settings that enforce it.
- Train your administrators on the operational steps and the evidence to collect, so your team can repeat the process.
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer after handover, with scope agreed in writing.
- Review FreeIPA release notes and security fixes with your team, and plan configuration changes before upgrades.
- Confirm with your independent assessor which evidence formats and sampling they expect before the assessment window.
