How FreeIPA helps meet PCI DSS requirement 8 for Linux access
FreeIPA can enforce password length, password history, lockout and one-time-password multi-factor authentication centrally for Linux access into a cardholder data environment (CDE), but it does not certify PCI DSS compliance, and no single platform satisfies requirement 8 on its own. Group password policies set a minimum length, a history length, a maximum number of failures, a failure count interval and a lockout duration through the pwpolicy commands, which cover much of what requirements 8.3.4, 8.3.6 and 8.3.7 ask for. Set the minimum length to 12 characters, since the 12-character rule for passwords used as authentication factors became mandatory on 31 March 2025, and confirm in your own test environment whether the configured quality checks enforce the required mix of numbers and letters. Your assessor will expect to see that test result, not a setting assumed from documentation. FreeIPA API reference for pwpolicy_mod lists the fields to review.
The multi-factor requirements in 8.4 depend on which access paths you route through FreeIPA. FreeIPA supports HOTP and TOTP tokens, including software tokens and hardware tokens, and can proxy OTP checks to an existing RADIUS server, which helps for SSH and console access on enrolled Linux hosts. Requirement 8.4.1 covers non-console administrative access into the CDE, 8.4.2 covers all access into the CDE, and 8.4.3 covers remote network access that could affect it. Each path needs its own check: a VPN, a bastion, a database client or an application login may authenticate outside FreeIPA entirely. Under v4.0.1, accounts that use only phishing-resistant authentication may be exempt from 8.4.2, but the PCI SSC states that this alone does not satisfy 8.4.1 or 8.4.3. Confirm how each path authenticates before you claim coverage.
Several requirements depend on processes, application logic and the assessor's judgment. Removing terminated users immediately (8.2.5) and disabling accounts inactive for 90 days (8.2.6) need a joiner, mover and leaver procedure that ties HR events to FreeIPA changes, plus a recurring review. Application accounts, service passwords and database users outside Kerberos need separate controls. Locking user IDs after no more than 10 invalid attempts (8.3.4) also depends on whether every login path reads the FreeIPA policy. Keep the configuration exports, test records and access reviews as evidence, and map them to the PCI DSS standard with your Qualified Security Assessor or internal assessor, who decides whether the evidence is sufficient.
Mapping PCI DSS requirements 8.2 to 8.4 to FreeIPA capabilities
This table maps the PCI DSS requirements in scope for Linux and service access to what FreeIPA documents and what your team must configure. Read each row as a question: does the platform setting exist, what must be set, and what evidence will an assessor ask for. The main takeaway is that FreeIPA covers much of the password, lockout and OTP work, but MFA scope and the numeric-and-letter rule still need confirmation against your own policy and access paths.
| Requirement | Platform capability as documented | Configuration needed |
|---|---|---|
| 8.3.6: Password length and character types | Group password policies set a minimum length through the pwpolicy settings in the FreeIPA API reference. | Set minimum length to at least 12 characters for CDE accounts. Confirm with your assessor and the configured policy that numbers and letters are both required, since the policy setting alone may not enforce both. |
| 8.3.4: Lockout after invalid attempts | Group password policies define maximum failures, failure count interval and lockout duration. | Set maximum failures to 10 or fewer and a lockout duration of at least 30 minutes, or a rule requiring identity confirmation. Test a lockout on a non-production account and keep the result. |
| 8.3.7: Password history | Group password policies set history length. | Set history length to at least 4 so the last four passwords cannot be reused. Confirm that the setting applies to every policy that governs CDE accounts. |
| 8.4.1: MFA for non-console administrative access into the CDE | OTP (HOTP and TOTP) and RADIUS proxying are documented for two-factor authentication. | Require OTP or another second factor for administrative sudo and SSH paths into the CDE. A phishing-resistant passkey alone does not satisfy this requirement under PCI SSC FAQ 1596. |
| 8.4.2: MFA for all access into the CDE | OTP is documented for two-factor authentication. Passkey support depends on the FreeIPA version you deploy, so confirm it. | Apply MFA to every login path into the CDE. Phishing-resistant authentication may qualify for an exception under v4.0.1 and PCI SSC FAQ 1595, but only for accounts that use it exclusively. Document which accounts use the exception. |
| 8.4.3: MFA for remote network access into the CDE | OTP is documented for remote logins, and Kerberos ticket policy determines when a second factor is required. | Confirm that VPN, bastion and remote SSH paths enforce MFA at the network or host layer. FAQ 1596 means a passkey alone does not satisfy this requirement. |
| 8.2.5 and 8.2.6: Access removal and inactive accounts | Disabling or deleting users and host access rules are managed centrally in FreeIPA. | Set a process to disable inactive CDE accounts within 90 days and revoke terminated users immediately. Confirm the inactivity check runs on a schedule and keep its output as evidence. |
Configuring password length, history and lockout in FreeIPA
Set the CDE password policy as a dedicated FreeIPA group password policy attached to the group that holds CDE users and service accounts, then check each requirement value against the effective policy rather than against the value you intended to set. FreeIPA group password policies carry the minimum length, history length, maximum failures, failure count interval and lockout duration, managed through the pwpolicy commands (see the pwpolicy_mod API reference). Requirement 8.3.6 calls for at least 12 characters (or eight where a system cannot support 12) with both letters and numbers, requirement 8.3.4 caps invalid attempts at 10, and requirement 8.3.7 bars reuse of the last four passwords. Confirm which settings your FreeIPA version enforces for character classes and which are checked only at the policy layer, and test each one against a throwaway account.
The lockout setting needs care because the requirement offers two outcomes: a lock lasting at least 30 minutes, or a lock held until the identity is confirmed. Choose one deliberately and document it. A short lockout duration with a generous failure count interval satisfies the 30-minute option only if the duration you configure is at least 30 minutes and the failure window is reset as you expect. Test the sequence end to end: ten failed Kerberos or SSH attempts, the lock event, the wait, and a successful login after the lock expires. Also confirm which services honor the policy, since a service that authenticates outside the Kerberos path may not show the same lockout behavior.
Policy precedence determines what happens to accounts outside the CDE group. Users who are not members of the group receive the global policy or another group policy, depending on how precedence is resolved in your deployment, so a user who is later added to a CDE group or who holds membership in two groups may not get the stricter values you expect. Map every account with CDE access, including shared and service accounts, and confirm its effective policy with ipa pwpolicy-show --user for a test account in each group combination. Record the output, the date, the FreeIPA version and the account used, and keep it with your change records so an assessor can see what the policy actually enforced.
Choosing OTP, passkeys or RADIUS for MFA into the CDE
FreeIPA supports two-factor authentication with HOTP and TOTP tokens, covering software tokens and hardware tokens such as YubiKeys, according to the FreeIPA OTP design page. Because the tokens are enrolled and checked by FreeIPA itself, the OTP check lives in the same identity layer that enforces your password policy, which keeps the authenticator lifecycle in one place for evidence. Requirement 8.4.1 covers non-console administrative access into the CDE and 8.4.3 covers remote network access, so OTP should be planned for both paths as a second factor on top of the password.
- Native token handling: FreeIPA stores and validates the OTP tokens, so token enrollment, disablement and removal are recorded against the user identity.
- Hardware tokens: YubiKeys and similar devices are a documented option, and you should confirm the exact model and firmware your team will issue.
- Lifecycle on departure: Revoking or disabling a user must also disable their tokens, since 8.2.5 requires access for terminated users to be revoked immediately.
- Phishing resistance: OTP codes can be phished, so FAQ 1595 and 1596 do not treat them as phishing-resistant authentication for the purposes of 8.4.2.
Confirm the console, SSH and sudo paths your administrators actually use, and test that each one prompts for the OTP factor rather than accepting the password alone.
FreeIPA can proxy OTP checks to an existing RADIUS server, according to the FreeIPA OTP design page. This suits an organization that already runs a RADIUS-based MFA service and wants FreeIPA to remain the source of users and Kerberos identities while the second factor is validated elsewhere. The design adds a dependency: the RADIUS service, its network path and its own logging become part of the authentication evidence you must produce for the assessor.
- Existing investment: The option fits where an MFA platform is already approved and assessed for the CDE.
- Added dependency: An outage or misconfiguration in the RADIUS path can block administrators, so plan a documented break-glass procedure.
- Split evidence: Authentication logs will sit in two systems, so define which logs the assessor will sample and where they are retained.
- Scope: The RADIUS server and its connections may themselves fall within the CDE or the connected scope, which should be confirmed in your scoping exercise.
Confirm with the RADIUS vendor which factor types it supports and whether its own authentication meets your requirement 8 position before you rely on it.
Passkeys and smart cards are a separate path from OTP. PCI SSC FAQ 1595 says FIDO2-compliant synced passkeys qualify as phishing-resistant authentication under the MFA exemption for 8.4.2, but FAQ 1596 states that this alone does not satisfy 8.4.1 or 8.4.3. Those requirements still require multi-factor authentication for administrative and remote access, so a passkey used as the only factor on a remote or administrative path needs a second, verified factor alongside it. Confirm the current passkey and smart card support in your FreeIPA version before designing around it, since recent 4.x releases have added capabilities in this area.
- Account-level exemption: Under 8.4.2, accounts using only phishing-resistant authentication may be exempt from MFA, which is narrower than a blanket exemption.
- Administrative and remote paths: Passkeys alone do not meet 8.4.1 or 8.4.3, so pair them with a second factor for those paths.
- Synced passkeys: FAQ 1595 specifically covers FIDO2-compliant synced passkeys, so confirm the authenticator product and its certification status.
- Certificate mapping: Smart card logins depend on certificate mapping and the Kerberos configuration, which need separate testing.
Confirm the passkey or smart card features your FreeIPA release and client distributions support, and document how each path meets 8.4.1, 8.4.2 and 8.4.3.
Evidence an assessor will examine from FreeIPA
An assessor testing requirement 8 controls will ask for proof that the settings were in force, who could use them, and when they changed. The cards below cover the artifacts that answer those questions, and each one needs a date and a named owner before it reaches an assessment folder. The assessor decides whether any artifact is sufficient.
Exported password policy settings
Export the effective policy from FreeIPA with the pwpolicy commands, covering minimum length, history length, maximum failures, failure count interval and lockout duration for every group that holds cardholder-environment access. Compare the export against the values your written standard requires for requirements 8.3.4, 8.3.6 and 8.3.7. Store each export with its timestamp and the administrator who ran it, and re-export after any change. Also confirm which policy applies to service accounts, since a group policy may not cover them.
User and group membership reports
Produce a dated report of every account that can reach CDE hosts, showing direct and nested group membership, host-based access control rules and sudo rules that grant privilege. The assessor uses this to check that each account is unique, approved and limited to what its role needs. Reconcile the report against your approved access list and record each exception with an owner and a decision date.
OTP token enrollment records
Keep a register of every OTP token enrolled for MFA into the cardholder data environment, showing token type (software HOTP or TOTP, or hardware), the user it is bound to, enrollment date, and the approver. Requirement 8.4 applies to non-console administrative access and all access into the CDE, so the register should map each token to the access path it protects. If you rely on passkeys or phishing-resistant authentication for any account, record that decision separately, because PCI SSC guidance treats it differently.
Authentication and admin audit logs
Retain authentication events from SSSD, the Kerberos KDC and the FreeIPA server, along with administrative changes made through the web UI and command line. Confirm that failed attempts, lockouts and MFA challenges are recorded with a user, host and time. Decide the retention period with your assessor and your forensic team, then test that you can pull a single user's history for a stated date range. Restrict who can alter or delete these logs.
Offboarding and inactive account records
Keep tickets showing when access for each terminated user was revoked, along with the disable or delete action taken in FreeIPA and the time it was completed. Requirement 8.2.5 expects revocation of terminated users to happen immediately, and requirement 8.2.6 expects inactive accounts to be removed or disabled within 90 days. Run a periodic report of last-login dates to find accounts that have crossed that threshold, and file each review with its reviewer and result.
Policy change records
Track every edit to password policies, OTP settings and group membership rules as a change record with the requester, approver, reason, and before and after values. Export the FreeIPA configuration at each change window so the assessor can see the state before and after. Group these records by quarter so the evidence set for an assessment period is complete without gaps. Ask your assessor which change approval standard they will accept.
Configuration sequence for a CDE-scoped FreeIPA deployment
This sequence takes FreeIPA from scope definition to a repeatable set of PCI DSS requirement 8 controls for Linux and service access into the cardholder data environment, with evidence captured at each stage. It is ordered so that each control is tested before the next one depends on it.
Confirm CDE scope and in-scope hosts
Start by listing every system that stores, processes or transmits cardholder data, plus any system that could affect the security of that environment, including the Linux hosts, databases and service accounts behind them. Your QSA or internal assessment lead should sign off on this inventory before any configuration changes, because it decides which accounts fall under requirement 8 and which hosts must enroll. The step is done when you have a written list of in-scope hosts, groups and service identities that every later step references.
Install or verify FreeIPA replicas
Verify or build the FreeIPA topology against the vendor deployment recommendations, which advise at least two to three replicas in each datacenter, dedicated servers without other applications, and no more than four replication agreements per replica. Confirm that the server holding certificate renewal and CRL publication is known and monitored. The step is done when
ipa server-role-findand replication checks show healthy agreements across all replicas that serve the CDE.Create the CDE group password policy
Create a dedicated group for CDE users and set its password policy with
ipa pwpolicy-addoripa pwpolicy-mod, covering minimum length, history length, maximum failures, failure count interval and lockout duration. Confirm the policy meets the 12-character minimum (or eight where a system cannot support 12) with both letters and numbers, the four-password history rule and the lockout threshold of no more than 10 invalid attempts. Test each rule with a throwaway account and record the results. The step is done when rejected passwords, reuse attempts and lockout behavior match the written requirement.Enroll MFA tokens for CDE access
Enroll OTP tokens (HOTP or TOTP) or hardware tokens for every user who reaches the CDE, and decide whether phishing-resistant passkeys or smart cards will serve any group, noting that the PCI SSC guidance on phishing-resistant authentication does not by itself satisfy the MFA requirements for administrative or remote access. Confirm that the MFA check is enforced in the Kerberos login path for each in-scope host, not only in the web UI. The step is done when a test login to a CDE host fails without the second factor and succeeds with it, and the token inventory is exported.
Restrict access with HBAC and sudo
Build host-based access control rules that allow only the CDE group to log in to CDE hosts, and create sudo rules that grant privileged commands only to named administrators. Keep administrative sessions tied to MFA-enforced services so that non-console administrative access is covered. Test by attempting logins from an account outside the group and from an account inside it. The step is done when denied and allowed attempts behave as designed and both rule sets are exported for the assessor.
Set inactivity and offboarding procedures
Document a procedure that disables accounts after the inactivity period required by requirement 8.2.6 and revokes access for terminated users immediately, then test it with a dormant test account and a leaver scenario. Confirm how FreeIPA disables, rather than deletes, accounts so that audit history survives. Make sure the procedure names who acts and where the change is logged. The step is done when a test account is disabled as the procedure states and the record is retained.
Collect baseline evidence
Export the password policy, HBAC rules, sudo rules, group membership, token inventory and audit log extracts into a dated evidence folder, and record the FreeIPA version in use. Compare the version against the vendor release notes, since security releases such as 4.13.4 fixed authentication flaws. Keep the export commands and output together so an assessor can rerun them. The step is done when a reviewer who did not configure the system can trace each requirement 8 control to a stored artifact.
Back up before any change and retest
Take a full
ipa-backupbefore every change to the CDE configuration. The vendor warns that restoring an outdated backup into an active replica topology can break replication, so restore only into a planned recovery procedure and never into a live topology without a replication check. After each change, rerun the password, lockout, MFA, HBAC and offboarding tests and update the evidence folder. The step is done when the retest matches the baseline or each difference is explained and approved.
Questions buyers ask before configuring FreeIPA for requirement 8
Does FreeIPA alone make a cardholder data environment compliant with PCI DSS?
No. FreeIPA is an identity and authentication platform, and it covers only part of requirement 8 for the systems it manages. PCI DSS applies to the whole cardholder data environment, including network segmentation, logging, change control, vulnerability management and the people and process controls in the other requirements. FreeIPA can enforce password length, history and lockout settings through group password policies, and it can enforce OTP for logins, but you still have to show that every access path into the CDE uses it. Systems outside FreeIPA, such as application-level accounts, vendor consoles and cloud management planes, need their own assessment. Your assessor, a Qualified Security Assessor or your acquirer's process, decides what counts as compliant.
What drives the cost of a FreeIPA requirement 8 project, and who pays for what?
Cost depends on the size of the CDE, the number of Linux hosts and services that authenticate into it, the number of administrators, and how many MFA paths you must cover. The main cost components are design work (mapping which accounts and access paths reach the CDE), server build and hardening, client enrollment, policy configuration, MFA rollout and token handling, testing, and the evidence pack. Your internal team pays for staff time and any hardware or cloud capacity you run. A partner is paid for the scoped work. Most of the cost is one-time, but token issuance, policy reviews, backups, patching and quarterly access reviews recur. Ask any provider for a quote that lists each component, its deliverables and the hosts and users it covers.
How long does a FreeIPA requirement 8 implementation take?
Duration depends mainly on host count, the number of distinct access paths into the CDE, and how far you roll out MFA. A small estate with a few hosts and a single admin path moves faster than a multi-site CDE with many service accounts, legacy applications and staged user enrollment. Plan time for the design review, a pilot on non-production hosts, a staged rollout that keeps break-glass access working, and an evidence walkthrough. Each MFA group needs its own enrollment window and support plan. Ask for a written timeline in the scope document, with milestones tied to host groups and user cohorts rather than a single go-live date.
What must our internal team provide before the work starts?
Your team needs to supply the information and access that no external party can derive on its own. This includes an inventory of Linux hosts and services in or connected to the CDE, a list of user groups and administrative roles, the current access paths (SSH, console, jump hosts, VPN and remote access), existing directory or LDAP sources, DNS and time services, and the change windows for production. You also need a named owner who can approve the password and lockout values, a decision on the MFA method for each group, a plan for issuing and replacing tokens, and access to your QSA or assessor's documentation requirements. Missing inventory data is the most common cause of delay.
Can our own team configure FreeIPA for PCI DSS requirement 8 without a partner?
Yes, if your team has Linux, Kerberos, LDAP and PKI skills and can carry the work through an assessment. FreeIPA is open-source under GPL-3.0-or-later with no paid edition, so the software itself carries no license fee, but you own the operation, upgrades and security fixes. The release notes for 4.13.4 describe two CVEs fixed in that stabilization release, which shows why patching must be a standing task. The harder parts are proving the design to an assessor, testing lockout behavior and MFA failover, and keeping evidence current. If those skills are thin, a fixed-scope engagement or a retainer for support can cover specific tasks while your team keeps ownership.
How does FreeIPA change with PCI DSS v4.0.1 as the only active version?
PCI DSS v4.0.1, published 11 June 2024, is the only active version, since v4.0 retired on 31 December 2024. The v4.0.1 revision made no changes to the requirements, so the rules you design against are the 4.0 requirements as now in force. The relevant points for FreeIPA are password length of at least 12 characters (or eight where the system cannot support 12), user lockout after no more than 10 invalid attempts, reuse limits on the last four passwords, MFA for non-console administrative access and all access into the CDE, and removal or disabling of inactive accounts within 90 days. The PCI SSC has also announced a request for comments that ran from 3 June to 20 July 2026, but it has not announced a release date for a new version, so confirm current guidance before you rely on it.
What evidence will a QSA ask for from FreeIPA on requirement 8?
Assessors typically ask for the configured policy values, proof that they apply to the in-scope hosts and accounts, and samples showing they work. Prepare exports of the password policies, lockout settings and MFA configuration, a list of accounts with their status and last login, records of account disablement and access revocation, and logs of failed logins and lockouts. Also prepare the MFA enrollment records and token lifecycle procedure, and an explanation of how each access path into the CDE is covered. Test lockout and reuse behavior in a controlled way and keep the results. FreeIPA produces some of this data, but you must confirm which logs and reports your environment retains and how long you keep them.
Who validates PCI DSS and what DeployOpen prepares
PCI DSS validation is done by an assessor or by the entity itself, never by the standard's owner or by DeployOpen. The PCI Security Standards Council owns and maintains PCI DSS, but it does not enforce compliance. The payment brands decide which entities must validate and run any enforcement programs. Validation is documented either as a Report on Compliance completed by a Qualified Security Assessor, or as a Self-Assessment Questionnaire, and each is closed with an Attestation of Compliance. A certificate is not accepted as validation. Confirm with your acquirer or payment brands which route applies to your organization and which SAQ type fits your environment before you plan the work.
For requirement 8, the assessor will test what FreeIPA actually does, not what the design document says. Expect them to examine the password policy objects for the groups that hold CDE access, the lockout settings, the password history configuration, the OTP or passkey enrollment records for administrators and remote users, and the process used to disable inactive or terminated accounts. Ask your QSA early whether they accept the FreeIPA password policy output and the authentication logs as evidence, and whether any MFA design depends on phishing-resistant authenticators, since that changes which requirements the assessor will test against.
DeployOpen prepares the configuration, the change records and the evidence package that your assessor or internal team uses. It does not write the Report on Compliance, sign an Attestation of Compliance or certify that your environment is compliant. In practice that means a written scope of which FreeIPA servers, clients, sudo and HBAC rules and identity sources sit inside the CDE, exports of the policy and rule settings with dates, and a mapping from each requirement to the artifact that proves it. Your organization remains responsible for the final validation decision and for the controls operating day to day after the engagement ends.
How DeployOpen scopes and delivers FreeIPA requirement 8 work
DeployOpen plans, implements, hardens, documents and supports FreeIPA inside your own infrastructure, including the password, lockout, MFA and evidence settings that PCI DSS requirement 8 examines. Work starts from a written scope that names the in-scope systems, the CDE boundary and the controls each system must meet.
How we scope
- Engagements are fixed-scope, with systems, deliverables and timelines agreed in writing before work starts.
- The scope lists which Linux hosts, service accounts and administrative paths sit inside the cardholder data environment.
- We map each in-scope account type to the relevant requirement 8 controls and record where a customized approach is proposed.
- Your qualified assessor should review the scope early, since they decide what evidence they will accept.
How we build
- We configure group password policies for minimum length, history, maximum failures, failure interval and lockout duration.
- OTP enrollment for MFA into the CDE is set up with HOTP or TOTP tokens, or proxied to an existing RADIUS server where you already run one.
- Host access and sudo rules are built so only named groups reach CDE hosts, and every rule is tested with a login from each path.
- Passkey or other phishing-resistant options are assessed against current PCI SSC FAQ guidance before any are enabled.
How we hand over
- Handover includes a configuration record of every pwpolicy setting, OTP token process and access rule, with the values in force.
- Test evidence shows failed-login lockout, password history rejection and MFA prompts recorded for each in-scope access path.
- Runbooks cover onboarding, offboarding within the required timeframes, token replacement and backup and restore of the topology.
- Your team receives a list of items your assessor must confirm independently, since DeployOpen prepares evidence but does not issue attestations.
How we support
- Ongoing support, upgrades and periodic re-testing of authentication settings are available as a retainer.
- Security releases affecting FreeIPA are reviewed against your deployment, including recent fixes to LDAP access control and API authentication.
- Changes to the CDE boundary or to PCI DSS guidance trigger a review of affected policies and evidence before the next assessment.
- Confirm with DeployOpen what support window, response terms and upgrade scope a retainer covers before signing.
