How FreeIPA helps meet NIST SP 800-171 identification and authentication requirements
FreeIPA supports the identification and authentication requirements 03.05.01, 03.05.03, 03.05.07 and 03.05.12 in NIST SP 800-171 Rev. 3, but it does not make a system compliant and it does not certify anything. Your team still owns the design, the settings and the evidence an assessor will examine. For unique identification (03.05.01), each person gets one directory identity and one Kerberos principal, and processes acting for that person can be tied to the same identity. For multi-factor authentication (03.05.03), FreeIPA supports HOTP and TOTP tokens, including hardware tokens, and can proxy OTP checks to an existing RADIUS server.
The version question comes first. NIST published Rev. 3 on 14 May 2024, and it remains the current NIST version, but the CMMC Level 2 rule (32 CFR 170.14(c)(3)) still ties DoD contractors to the 110 requirements of Rev. 2. DoW Class Deviation 2026-O0025, Revision 3, signed 3 September 2026, names Rev. 2 explicitly. A FAR overhaul proposed rule would move CUI contractors to Rev. 3 with organization-defined parameter values published by the DoW CIO, and that rule was not final as of October 2026. Confirm in writing which version your contract requires, and who assigns the parameter values for requirements such as 03.05.07 and 03.05.12, because NIST does not assign them.
Plan the evidence before the build. For 03.05.07, the dictionary check (ipapwddictcheck) and user-name check (ipapwdusercheck) in the password policy are both off by default, so enable them deliberately and keep a record of the settings in effect. For 03.05.12, decide how lost, compromised or damaged OTP tokens are revoked, who approves it, and how enrollment and removal are logged for each token. Also decide the re-authentication circumstances required under 03.05.01. A requirement counts as met only when its assessment objectives are satisfied with evidence in final form, so keep the policies and token records in finished, dated versions.
Which NIST SP 800-171 requirements map to FreeIPA features and settings
This table compares four Rev. 3 identification and authentication requirements with the FreeIPA features that support them and the configuration each one needs. Read each row as a starting point for your assessment evidence, since FreeIPA supplies mechanisms while your organization sets the parameters and policy. The main takeaway is that the dictionary and user-name password checks are off by default and must be enabled deliberately.
| Requirement | FreeIPA capability | Configuration needed |
|---|---|---|
| 03.05.01 Unique identification and authentication | One Kerberos principal per user, with groups and host-based access rules tied to that identity | Disable shared and generic accounts, enforce individual logins on IPA clients, and document how processes run under a named user |
| 03.05.03 MFA for privileged and non-privileged accounts | HOTP and TOTP tokens, including hardware tokens, and RADIUS proxying of OTP checks | Enable OTP for every account in scope, enforce it for privileged and non-privileged logins, and confirm which services accept the second factor |
| 03.05.07 Password checks and complexity | Password policy with the ipapwddictcheck and ipapwdusercheck options, both off by default | Enable both checks, define length and composition rules, and add an organization-defined list of commonly used or compromised passwords |
| 03.05.12 Authenticator management | OTP token enrollment, revocation and administrative disablement of tokens | Set issuance and identity verification steps, a lost or compromised token procedure, and a first-use default authenticator change |
| Organization-defined parameters | FreeIPA does not assign ODP values for these requirements | Your organization must set the values, such as lockout thresholds, password rules and re-authentication intervals, and record them in your System Security Plan |
Configuring MFA for privileged and non-privileged access
Privileged access is the first place an assessor will look for multi-factor authentication. In a FreeIPA estate, administrators typically reach Linux hosts through SSH, sudo and, for some roles, the console or the IPA web UI. Each of these paths authenticates through a different component, so OTP enforcement must be planned per path rather than declared once for the domain. Set the OTP requirement on the accounts or groups that hold administrative rights, then verify that sudo prompts for a second factor where your policy requires it.
- Identify privileged accounts: Build a list of users and groups that hold sudo rights, host administration roles or IPA administrative privileges, and tie each to a named owner.
- Assign OTP tokens to those accounts: Enroll HOTP or TOTP tokens for each privileged user, including hardware tokens, and record the token type and issuance date.
- Test sudo separately from login: Confirm whether a password-only sudo prompt still appears after SSH login with OTP, since the two checks are independent.
- Document break-glass accounts: Decide how emergency access is protected, who holds it, and how its use is logged and reviewed.
- Confirm the IPA web UI path: Check whether administrators who sign in to the web interface are challenged for OTP under your configuration.
Before relying on this tab, confirm with your own test hosts which login paths enforce OTP and which fall back to passwords.
Non-privileged accounts still fall within the scope of NIST SP 800-171 Rev. 3 requirement 03.05.03 when they access systems that handle controlled unclassified information. Standard users are often the largest population, so the design question is how to apply MFA without making routine work unworkable. Decide which standard users must authenticate with a second factor, which may use a password alone, and whether the answer changes by system or by data classification. Record that decision in the access policy so the assessor can trace it.
- Map standard access to systems holding CUI: List the hosts, applications and file shares where non-privileged users reach CUI, since these define the MFA scope.
- Choose an OTP model per population: Consider software TOTP for most users and hardware tokens for users who cannot use a phone or who require stronger assurance.
- Plan token enrollment and recovery: Define how users enroll, how lost tokens are replaced and how the replacement is verified in person or through an approved process.
- Check Kerberos ticket behavior: Confirm how OTP interacts with ticket lifetimes so users are not challenged in ways that break batch or service workflows.
- Review exceptions: Any account that cannot use OTP needs a documented exception, a compensating control and a review date.
Check with your assessor how they expect non-privileged MFA scope to be defined and evidenced for your system boundary.
Console and SSH logins reach the same host through different authentication stacks, and the MFA behavior can differ between them. SSH sessions may use Kerberos, public keys or passwords depending on client and server configuration, while local console logins go through PAM and may not present an OTP prompt at all. Because a single host can accept several methods, an assessor will expect you to show which methods are permitted, which are disabled and what happens when a user tries a password-only path.
- Inventory every login method: For each host class, list console, SSH password, SSH key, Kerberos and sudo methods, and mark which enforce OTP.
- Restrict password-only access: Disable or constrain password-only paths where the policy requires MFA, and verify the change on a test host first.
- Account for SSH keys: Decide whether key-based SSH satisfies your MFA requirement, since a key alone is one factor, and document the answer.
- Test the console separately: Physically or through out-of-band access, confirm whether the local console challenges for OTP.
- Keep logs of each path: Make sure authentication events show the method used so evidence can be sampled by path.
Verify each login path on representative hosts before writing the control narrative, because configuration drift between hosts is a common source of gaps.
FreeIPA supports two-factor authentication with HOTP tokens defined in RFC 4226 and TOTP tokens defined in RFC 6238. Both can run as software tokens on a phone or as hardware tokens such as YubiKeys. The choice affects enrollment effort, recovery, user experience and how you evidence token ownership, so it should be made before rollout rather than after the first complaint. Hardware tokens generally give a stronger assurance story for privileged users, while software tokens scale more easily across a broad population.
- HOTP versus TOTP: HOTP is counter-based and TOTP is time-based. Confirm which your clients and token software support, and test resynchronization behavior.
- Software tokens: Plan how users register authenticator apps, what happens on device loss and whether any personal devices are permitted.
- Hardware tokens: Track serial numbers, assignment, custody and return or destruction when staff leave.
- Token lifecycle records: Keep issuance, revocation and replacement records, since these form part of authenticator management evidence.
- Confirm supported hardware: Check the current FreeIPA documentation and your token vendor's documentation for the exact hardware and protocol combinations you intend to use.
Confirm with your token vendor and your FreeIPA version which hardware models and protocol modes your deployment has tested.
Some organizations already run a RADIUS server that holds OTP credentials or integrates with a token platform. FreeIPA can proxy OTP checks to that server, so the existing second-factor system remains the source of truth while FreeIPA continues to handle Kerberos and directory identity. This reduces duplicate enrollment but adds a dependency: if the RADIUS service is unreachable, OTP logins may fail, and the failure mode must be understood before go-live. Decide whether this model fits your system boundary, since the RADIUS server and its data may fall inside the assessed scope.
- Confirm the RADIUS dependency: Identify the server, its owner, its location and whether it is inside your system boundary.
- Plan for outages: Document what users experience during a RADIUS outage and who approves any temporary fallback.
- Secure the shared secret and transport: Store the RADIUS shared secret under your secrets process and restrict network paths to the proxy.
- Align token records: Make sure the RADIUS side and the FreeIPA side agree on which users have active tokens.
- Test the full path: Run authentication tests for each user type and each login path after any RADIUS change.
Confirm with the owner of the existing RADIUS platform how its audit records will be retained and produced for your assessment.
What evidence FreeIPA produces for a NIST SP 800-171 assessment
An assessor for NIST SP 800-171 Rev. 3 requirements 03.05.01, 03.05.03, 03.05.07 and 03.05.12 will ask for records, not configuration screenshots alone. The cards below list the FreeIPA exports and logs that answer those questions, and the checks to run before you hand them over.
Password policy exports
Export the global and group password policies with the pwpolicy tools and keep dated copies. Confirm that the dictionary check (ipapwddictcheck) and user-name check (ipapwdusercheck) are enabled, since both are off by default. An assessor will compare the exported values against the composition, history and lockout rules your organization defined for requirement 03.05.07, so record who approved each value and when it changed.
User and group records
Export user and group records showing that each person has one account with a unique identifier, and that shared or generic accounts are either absent or documented as exceptions. Requirement 03.05.01 also asks that identities be linked to processes acting on a user's behalf, so include service accounts and their owners. Check for duplicate accounts created during migrations before the export is taken.
OTP token inventories and assignments
Keep an inventory of every OTP token (software HOTP or TOTP, or hardware tokens) with its owner, enrollment date and status, plus the assignment history. Requirement 03.05.03 expects MFA for privileged and non-privileged access, so the inventory should show which accounts require a second factor and which do not. Confirm how your deployment handles RADIUS-proxied OTP checks, because those records may sit on the RADIUS side.
Sudo and HBAC rule exports
Export sudo rules and host-based access control rules that define who can reach which hosts and which privileges they hold. Assessors use these to test whether privileged access is limited and whether non-privileged accounts are kept out of administrative paths. Note that sudo and HBAC rules are not migrated by the standard user-migration command, so confirm that exports taken from a migrated estate match the source system's rules.
Audit and access logs
Collect authentication logs from the IPA servers and the SSSD clients, including failed attempts, lockouts and OTP validation results. Set retention to match your own policy and confirm that logs cannot be altered by the accounts they record. Requirement 03.05.01 requires re-authentication in circumstances you define, so logs should show that re-authentication events occur as configured.
Lost and compromised authenticator procedures
Document how a lost, damaged or compromised OTP token or password is reported, verified, revoked and replaced, and keep the tickets or records from real events. Requirement 03.05.12 also covers identity verification at initial distribution and changing default authenticators at first use. Assessors will interview staff on these steps and compare them against the revocation records, so the procedure and the records must agree.
Setting password policy and dictionary checks for requirement 03.05.07
The dictionary check and user-name check in FreeIPA are off by default, so enabling them is a configuration task you must plan and verify before an assessment. Both are exposed through the password policy API as ipapwddictcheck and ipapwdusercheck on the pwpolicy settings, and the pwpolicy_mod API reference is the place to confirm the exact option names for your FreeIPA release. Requirement 03.05.07 expects new passwords to be checked against a regularly updated list of commonly used, expected or compromised passwords, and it expects composition and complexity rules that you define. Turning on the check without a list behind it does not satisfy the requirement, so the configuration and the list need to be documented together.
The list itself is your organization's responsibility. FreeIPA does not supply a current compromised-password list on its own, and the dictionary check only tests candidates against the words and entries you give it. You need to decide where the list comes from (a commercial feed, a public breached-password corpus, or an internal list of organization-specific terms), who approves it, how often it is refreshed, and how a refresh is logged. Write down the refresh interval as an organization-defined parameter, because NIST leaves those values to the nonfederal organization when no federal agency sets them.
Confirm the list sources, refresh cadence and composition rules with your assessor before you build the evidence pack. Ask whether they expect a dated change record for each list update, how they want the password policy export and the pwpolicy settings captured, and whether composition rules set in FreeIPA match the wording you give in your system security plan. The most common gap is a policy that is configured correctly but has no owner and no refresh record, so assign that owner and keep the first refresh in the evidence set.
What FreeIPA does not cover for NIST SP 800-171
FreeIPA can carry much of the identification and authentication work in requirements 03.05.01, 03.05.03, 03.05.07 and 03.05.12, but it does not close them alone. The cards below mark where FreeIPA stops and other controls, procedures and assessors take over.
Application and non-Linux accounts
FreeIPA authenticates Linux hosts, Kerberos-aware services and users who sign in through SSSD. Web applications, SaaS tools, network devices, databases with local users and Windows endpoints often keep their own accounts. Inventory every system that handles CUI and confirm which ones bind to FreeIPA. Any account outside that boundary needs its own unique identification, MFA and password settings documented in the system security plan.
Authenticator issuance and recovery procedures
Requirement 03.05.12 expects identity verification before an authenticator is handed out, documented steps for lost or compromised tokens, and revocation. FreeIPA can enroll and disable OTP tokens, but it does not check the person at the desk. Write the issuance and revocation procedure, name who approves it, and keep the request and disable records as evidence.
Organization-defined parameter values
Rev. 3 leaves several parameters for the organization to set, such as password composition rules, re-authentication intervals and lockout thresholds. NIST does not assign these values, and an agency may later publish them. Choose each value in writing, map it to the FreeIPA setting that enforces it, and confirm the current federal position before the assessment.
Rev. 2 versus Rev. 3 scope
CMMC Level 2 assesses against the 110 requirements of Rev. 2, while NIST's current version is Rev. 3 with 97 requirements. Contract clauses and a pending FAR proposal point in different directions, so the controlling version depends on the contract. Ask the contracting officer which revision applies before mapping FreeIPA settings to requirement numbers.
The assessment and C3PAO certification
DeployOpen prepares configurations, procedures and evidence, but it does not issue audit reports or certifications. Level 2 certification assessments are performed by C3PAOs authorized by The Cyber AB, and self-assessments follow the assessment objectives in NIST SP 800-171A. Confirm the current assessment path with the sponsor and the assessor before scoping evidence.
FIPS and encryption requirements
Requirement 03.05.07 covers protecting passwords in transit and storage, but FIPS-validated cryptography and encryption of CUI at rest and in transit belong to other requirements in the system and communications families. FreeIPA's Kerberos and LDAP settings do not replace those controls. Document which cryptographic modules protect each path and confirm module validation status with the vendor.
Configuration sequence for a CUI-scoped FreeIPA deployment
This sequence takes a FreeIPA identity layer from scoping through replicated servers, client enrollment, password and OTP controls, backups and assessor evidence. Each step ends with a check you can record for a NIST SP 800-171 assessment.
Confirm scope, version and assessment target
Start by listing which systems store, process or transmit CUI, which contract or regulation sets the assessment target, and which FreeIPA release you will deploy. The NIST SP 800-171 Rev. 3 requirements (03.05.01, 03.05.03, 03.05.07 and 03.05.12) apply to the systems in that boundary, but the assessment target itself must be confirmed with your contracting officer or assessor because federal rules currently point to different revisions. Record the release you pick and check its release notes for fixes, since the 4.13.4 stabilization release fixed two CVEs. The output is a signed scope statement naming the in-scope hosts, the revision and the FreeIPA version.
Deploy replicated FreeIPA servers
Build the server topology before any client or policy work. Follow the FreeIPA deployment recommendations: 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 you use them. Keep the first server's role for certificate renewal and CRL publication in mind when you plan operations. The check at the end is a replication status that shows every server in agreement, plus a Kerberos login test against each replica.
Enroll Linux clients and configure DNS resolution
Enroll each in-scope Linux host as an IPA client so that identities, groups and host records are centrally managed and no local accounts are created for human users. Confirm that each client lists at least two DNS servers in its resolver configuration, as the deployment recommendations advise. Remove or lock local accounts that are not required for system operation, and record exceptions with a named owner. The output is an inventory showing every in-scope host enrolled, with its IPA host record and the list of remaining local accounts.
Set password policy with dictionary and user-name checks
Configure the global and group password policies through the pwpolicy settings, then turn on the dictionary check (ipapwddictcheck) and the user-name check (ipapwdusercheck). Both options are off by default, so the change must be made deliberately and verified. Set composition, length, history and lockout values to match the organization-defined parameters you documented in step one, since NIST does not assign those values. Confirm the result with a test that tries a common password and a password containing the user name, and capture the rejected attempts. The output is an exported policy record and test results tied to requirement 03.05.07.
Enforce OTP for privileged and non-privileged access
Enroll OTP tokens for every user who reaches the CUI boundary, using HOTP or TOTP software tokens or hardware tokens, and require a second factor on both privileged and non-privileged paths. Map the authentication requirement to access control rules so that remote and local logins to in-scope hosts cannot bypass the OTP check, and confirm that the Kerberos settings MFA depends on are in effect. If an existing RADIUS server is the chosen second factor authority, validate that the proxy path enforces OTP. The check is a documented login test for each path, showing a password-only attempt fails and an OTP-backed attempt succeeds.
Document token lifecycle and authenticator procedures
Write the procedures that cover identity verification at initial token distribution, the steps for a lost, compromised or damaged token, revocation, and the process for changing default authenticators at first use. Assign an owner for each step and specify the system record that proves it happened, such as a help-desk ticket and the token disable action in FreeIPA. Keep the procedures in the same controlled document set as the SSP. The output is an approved procedure document and a sample of executed tickets that show each step being followed, which is the evidence type requirement 03.05.12 requires an assessor to examine.
Enable backups and test a restore
Schedule ipa-backup on each server, choosing full backups or online data-only backups according to your recovery plan, and store copies outside the server that produced them. Read the backup documentation before any restore, because it warns that restoring an outdated backup into an active replica topology can break replication. Test the restore in an isolated environment and confirm that users, OTP tokens and policies come back as expected. The check is a signed restore test record with the date, the backup used, the systems involved and the verification results.
Collect evidence packages for the assessor
Assemble one evidence folder per requirement that lists the configuration exports, policy test results, enrollment inventory, OTP login test records, token lifecycle tickets and restore test record. Each artifact should carry a date and an owner, and the final versions should be kept rather than drafts, since assessors judge only final evidence. Ask your assessor which method they will use for each requirement and prepare to answer examine and interview questions. DeployOpen prepares this material, but the independent assessor or certification body makes the determination.
Questions buyers ask about FreeIPA and NIST SP 800-171
What drives the cost of a FreeIPA partner engagement for NIST SP 800-171 identification and authentication?
The largest drivers are the number of systems that handle controlled unclassified information, how many of them enroll as FreeIPA clients, and how much of the authentication estate already exists in some form. A partner is paid for planning, server build, client enrollment, policy configuration, MFA rollout, testing and the evidence pack, and each of those can be priced separately. FreeIPA itself is GPL-3.0-or-later with no paid edition, so the cost is labor, infrastructure and any hardware tokens you choose to buy. Ask for a quote that lists each deliverable, which parts are one-time and which recur, such as retainer support or upgrades, and which items depend on your environment. DeployOpen agrees scope, deliverables and timelines in writing before work starts, and provides a quote from that written scope.
How long does a FreeIPA identity build for CUI systems take?
Duration depends on scope: how many IdM servers and replicas you need, how many Linux hosts enroll, whether you migrate existing users from LDAP or Active Directory, and how many MFA paths must be proven. The FreeIPA deployment recommendations call for at least two to three replicas in each datacenter, which adds build and testing steps in multi-site designs. Confirm the timeline with a partner against a written scope rather than relying on a generic estimate. Ask for milestones that separate the identity build, the authenticator rollout and the evidence collection, because the evidence period is the part most often underestimated.
What must our team provide before a partner can start?
A partner needs a clear list of in-scope systems that process CUI, network and DNS layout, the cloud accounts, data centers or air-gapped networks where FreeIPA will run, and the names of the owners who approve identity and access decisions. You should also provide your current password and account policies, any existing directory or identity provider that holds users, and the MFA methods you already license or want to use, such as software tokens or hardware keys. Access to change windows, a test environment that mirrors production and a named contact for the assessment scope are equally important. Confirm each item during scoping so the written scope reflects what is actually available.
Can our internal team implement FreeIPA for NIST SP 800-171 without a partner?
Yes, if your team has Linux, Kerberos, LDAP and DNS skills, and the time to run a build, a test plan and an evidence process alongside normal operations. FreeIPA is community software, so no vendor license is needed, but the work includes server design, certificate authority decisions, client enrollment, password policy, OTP setup and backup procedures. The backup documentation warns that restoring an outdated backup into an active replica topology can break replication, which is the kind of failure internal teams should rehearse before go-live. Many organizations split the work, keeping day-to-day administration in-house and buying a fixed-scope build or security review from a partner.
Does FreeIPA alone satisfy NIST SP 800-171 requirements 03.05.01, 03.05.03, 03.05.07 and 03.05.12?
No. FreeIPA can support several requirements directly: unique user identities through Kerberos, MFA for accounts through HOTP and TOTP tokens, password policy with the dictionary and user-name checks, and centralized account records. However, the requirements also cover re-authentication circumstances, identity verification at distribution, lost or compromised authenticator procedures, and changes to default authenticators, and those are process and policy decisions you must document and operate. The dictionary and user-name checks are both off by default, so they must be enabled deliberately. An assessor will examine evidence from the whole system, including your procedures and the systems outside FreeIPA. Confirm the assessment scope and the applicable CMMC or contract version with your contracting officer or assessor before you rely on any mapping.
Which NIST SP 800-171 version should our FreeIPA evidence target?
Confirm this first, because the version affects which requirement numbers and parameters you document. NIST published Rev. 3 on 14 May 2024 and it remains the current NIST version. The CMMC rule still incorporates Rev. 2 through 32 CFR 170.14(c)(3), and the Department of War said on 13 July 2026 that it will enforce Rev. 2 in the interim. A FAR overhaul proposed rule would require Rev. 3 with organization-defined parameter values, but it was not final as of October 2026. Ask your contracting officer which version your contract names, and keep the requirement mapping in a form you can update.
What evidence will an assessor expect for FreeIPA identity controls?
Assessors look for configuration exports, policy settings, account and group lists, MFA enrollment records, authenticator issuance and revocation logs, and records of backups and restores. For NIST SP 800-171A, an assessor checks each objective with examine, interview and test methods, and a requirement is met only when all applicable objectives are satisfied with evidence in final form. Keep dated exports of password policy, the state of the dictionary and user-name checks, OTP token inventory, and the procedures for lost or compromised authenticators. Your partner can prepare the evidence pack, but independent assessors and certification bodies, not DeployOpen, issue any audit report or certification.
Scoping the CUI boundary and the assessment evidence
The CUI boundary decides which FreeIPA components fall under NIST SP 800-171 requirements, so draw it before you size the identity estate. Every system that stores, processes or transmits controlled unclassified information is in scope, and so is anything that can authenticate into one. For FreeIPA that usually means the IPA servers, every enrolled Linux client that touches CUI, the hosts that administer them, and any SSSD-backed services those clients run. A replica sitting in a separate network zone with no CUI access may still be in scope if it issues Kerberos tickets or holds credentials for in-scope systems. Confirm this boundary with your assessing body or sponsor before you write the system security plan, because scope errors are expensive to correct later.
Cloud placement changes the analysis. Under 32 CFR 170.17(c)(5), a defense contractor seeking CMMC Level 2 may store or process CUI in a cloud service only if that service is FedRAMP Authorized at the Moderate baseline or higher, or meets equivalent requirements. If you host FreeIPA servers or CUI-bearing clients on a cloud provider, the provider's offering must meet that condition, and you should ask the provider for its authorization package and boundary documentation. Whether a particular hosting arrangement is a FedRAMP-covered cloud service, or falls outside FedRAMP scope as a single-agency system, is a question for the assessing body and the cognizant contracting officer, not for your own reading of the scope statement. Record the answer in writing.
Assessors will examine evidence that your boundary matches reality. Keep an inventory of IPA servers, replicas and enrolled hosts with their roles and network locations, and show which of them hold CUI-facing access rules such as HBAC and sudo policies. Retain the password policy, OTP token records and authenticator lifecycle records for the in-scope population, dated and in final form, since drafts do not satisfy an assessment objective. Confirm with your assessor which artifacts they expect for each requirement, such as 03.05.03 multi-factor authentication for privileged and non-privileged accounts, and whether they will sample evidence from replicas as well as from the first server.
How DeployOpen scopes, configures and documents FreeIPA for NIST SP 800-171
DeployOpen plans, implements, hardens and documents FreeIPA inside your own infrastructure, including the identity controls that a NIST SP 800-171 assessment examines. The work starts with a written scope that maps each identification and authentication requirement to a configured FreeIPA setting, an operating procedure and an evidence source your assessor can review.
How we scope
- Engagements are fixed-scope, with systems, user populations, MFA coverage and deliverables agreed in writing before work starts.
- We inventory the Linux hosts, services and privileged accounts that handle CUI and confirm which are in the FreeIPA boundary.
- We confirm with you which organization-defined parameters, such as re-authentication triggers and lockout values, your assessment team expects.
How we build
- We configure password policy, dictionary and user-name checks, and OTP enrollment for privileged and non-privileged accounts according to the agreed design.
- We set up replicas, backups and client enrollment so that identities and authenticators survive a server failure without breaking replication.
- We test login, MFA, lockout and authenticator revocation paths against the assessment objectives you agreed to cover.
How we hand over
- You receive configuration records, runbooks and a requirement-to-setting map that cross-references NIST SP 800-171 requirement numbers.
- Authenticator lifecycle procedures cover issuance, loss, compromise and revocation, with the logs and tickets that prove each step was followed.
- Documentation is written for your team to operate, and we identify the items your assessor or C3PAO must determine independently.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover.
- Retainers can cover FreeIPA version reviews, such as checking security releases against your configuration before you apply them.
- DeployOpen prepares systems, controls and evidence for assessment. Independent assessors issue the assessment results, not DeployOpen.
