How FreeIPA helps meet NIS2 MFA and access control duties on Linux
FreeIPA can cover the identity side of NIS2 Article 21(2)(i) and (j) on a Linux estate, but it cannot cover the whole article. NIS2 is a directive, so essential and important entities meet its requirements through their national transposition laws, and the detailed technical expectations for Article 21(2) come from Commission Implementing Regulation (EU) 2024/2690. NIS2 creates no certificate of compliance. National authorities oversee compliance through inspections, security audits, information requests and fines, so the practical question is what evidence your FreeIPA configuration can show. Confirm with your competent authority which of these expectations apply to your sector and classification, since the Commission's July 2026 pages still describe proposed amendments to NIS2 that Parliament and the Council have not yet approved.
FreeIPA supplies the controls most often mapped to access control and authentication: a central identity store on 389 Directory Server, Kerberos single sign-on, two-factor authentication with HOTP and TOTP tokens, host-based access control (HBAC) and sudo rules, and account lifecycle through disabling and removing identities. Those features line up with the Regulation's expectations that each identity map to one person, that privileged accounts use separate credentials with multi-factor authentication, and that access change on role change or termination. Human resources security under Article 21(2)(i), background checks and termination procedures, physical access control, secured voice and video communications, and secured emergency communications are organizational or physical controls. FreeIPA does not provide them, so they need their own owners and evidence.
Plan the work around three decisions. First, decide which Linux hosts and privileged roles require OTP at login and sudo, and which use the Kerberos password policy alone, then record that decision against the asset classification, since the Regulation ties authentication strength to the classification of the asset accessed. Second, decide how HR joiner and leaver events reach FreeIPA, because a disabled account in a directory is only evidence if the removal was triggered and dated. Third, decide how the access register and periodic reviews will be exported from FreeIPA, for example with ipa user-find and ipa hbacrule-find output kept with review sign-offs. Check the exact procedure and output format against your FreeIPA version before you rely on it as evidence.
Mapping NIS2 Implementing Regulation 2024/2690 points to FreeIPA features
This table maps each Implementing Regulation 2024/2690 access and authentication point to the FreeIPA capability that supports it, the configuration it needs and the decision that stays with your organization. Read each row as a split: FreeIPA enforces and records the technical part, while policy, approvals and asset classification remain your responsibility. The main takeaway is that FreeIPA covers most of the mechanics, but the classification and review decisions must be made and documented outside the platform.
| Requirement | FreeIPA capability | Configuration needed | What the platform does not decide |
|---|---|---|---|
| 11.7.1 and 11.7.2: MFA or continuous authentication, strength matched to asset classification | OTP tokens under HOTP (RFC 4226) and TOTP (RFC 6238), hardware tokens such as YubiKeys, and RADIUS proxying of OTP checks | Enable OTP for the user groups that reach each asset class, and use HBAC to tie stronger login methods to higher-classified hosts | Which assets are classified at each level, and which authentication strength each level requires |
| 11.6.2: Credential change, lockout, session end and separate privileged credentials | Password policy with expiry and failed-login lockout settings, Kerberos ticket lifetimes, and separate admin identities | Set password policy per group, configure lockout thresholds, keep privileged accounts as distinct principals, and review SSSD session settings on clients | The predefined intervals, the failed-login threshold and the session timeout values, which must come from your own policy |
| 11.3.2(a): MFA for privileged and system administration accounts | OTP-based second factor on privileged principals, sudo rules that limit elevated commands, and HBAC rules for admin hosts | Assign OTP tokens to admin principals, require the factor in the Kerberos login path used for administration, and scope sudo to named commands | Which accounts count as privileged, and whether a shared admin path needs a compensating control |
| 11.2.2 and 11.2.3: Need-to-know, least privilege, separation of duties, register and periodic review | HBAC rules, sudo rules, user groups and role-based delegation, with audit records of changes | Model access as groups mapped to HBAC and sudo rules, keep change history, and export group and rule membership for review | The access register itself, the approval workflow, the separation-of-duties matrix and the review schedule |
| 11.5.2 to 11.5.4: Identity lifecycle, one identity per person, shared identities only with approval, prompt deactivation | Unique user principals, disabling or deleting accounts, and inactive-account handling in the directory | Create one principal per person, avoid generic shared accounts, and disable identities as soon as HR or a manager triggers removal | Who approves a shared identity, how HR events reach IdM, and how quickly deactivation must happen under your own procedure |
Matching authentication strength to asset classification
Implementing Regulation 2024/2690 requires users to be authenticated by multiple factors or continuous authentication where appropriate, with authentication strength matched to the classification of the asset accessed (Annex, points 11.7.1 and 11.7.2). That means the first task is not configuration but classification. Before any FreeIPA rule is written, list your Linux systems, assign each a class based on the data and services it supports, and record who owns that decision. A class register that maps every host to a strength level is the artifact that turns a generic MFA rollout into something an authority can test against.
FreeIPA can express those classes directly. Hosts are grouped into host groups, and HBAC rules tie a host group to the user groups allowed to log in there. Because each HBAC rule can be scoped to a different host group, you can allow password-only access to low-class systems and require an OTP-backed Kerberos login for higher classes, using the authentication indicator and Kerberos settings described in the MFA and smart card section of this guide. Confirm the exact combination your FreeIPA version supports for each class before you publish the policy, and test it on a non-production host group first. Privileged and administrative accounts need separate credentials and strong authentication under point 11.3.2(a), so model them as their own user group, not as exceptions inside a general rule.
OTP alone may not be enough for the highest classes. FreeIPA supports HOTP and TOTP tokens, including hardware tokens, and can proxy OTP checks to an existing RADIUS server. If your entity already runs a token platform on RADIUS, that proxy may let you reuse it, but confirm with the platform owner that the token estate, enrollment process and audit records meet the strength you have assigned to each class. For systems where a token may be shared, phished or left unattended, plan a stronger factor or a continuous control on top, such as session re-verification or shorter Kerberos ticket lifetimes, and document the residual risk you accepted and who approved it.
Evidence national authorities and auditors ask for from FreeIPA
NIS2 creates no certificate of compliance, so national competent authorities judge your access control and multi-factor authentication through inspections, security scans and information requests. The cards below are the records FreeIPA can export on request, and each one should be dated, stored outside the directory it describes and reviewed on a fixed schedule.
Password and OTP policy exports
Export the global password policy, per-group password policies and the OTP configuration as dated files, including the failed log-in lockout values and the rule that forces a credential change at first use, at set intervals and after suspected compromise. Compare each export with the policy your risk assessment approved, and keep the prior export so you can show when a setting changed. Confirm with your national authority which evidence format it accepts.
HBAC and sudo rule listings
List every host-based access control rule and sudo rule with its members, target hosts and services, and the named owner who approved it. Auditors check that access follows need-to-know and least privilege, so a rule that grants allow_all or a broad host group needs a documented justification. Export these listings on a schedule and diff them against the previous run.
User and group lists tied to people
Produce a register of user and group accounts that links each identity to one named person, with the approval for any shared identity and the role it supports. Access rights should change on role change and be recorded in this register, so include the date of the last group change for each person. Reconcile the list against your HR leaver feed each review cycle to show that unneeded identities were deactivated without delay.
Disable and termination records
Keep a log of every account disabled, locked or removed, with the trigger, the request ticket, the date and the operator who acted. FreeIPA records status changes, but the reason usually lives in your ticketing system, so link the two. Test one leaver case end to end before an inspection so you can show that sessions ended and group memberships were removed.
Privileged account inventory with MFA enrolment
Maintain a list of every administrative and system account, the members of privileged groups and the second factor each one has enrolled, whether a TOTP or HOTP token, a hardware token or a certificate. Privileged accounts need strong authentication and separate credentials, so flag any privileged user without an enrolled factor. Record the review date and who signed off, because an inspector will sample this list first.
Backup and replica topology records
Document the server layout, including which replicas run in each site, which servers hold the certificate authority or DNS roles, and the dates of your last full and data-only backups from ipa-backup. Restore tests carry weight here, so record each one with its outcome. Keep these records separate from the live directory so they remain available if the directory is unavailable during an incident.
Configuration sequence for NIS2 access control
This sequence turns a FreeIPA estate into a documented access control set-up that maps to the NIS2 access control and multi-factor authentication requirements, with each step leaving a record an auditor or national authority can inspect. The order matters: identity and host structure come first, then authentication, then the administrative and review processes that keep the access model accurate.
Confirm replication health before any change
Before changing policy, check that every IdM server in the topology is replicating cleanly and that the server holding certificate renewal and CRL publication (the first server, by default) is identified and reachable. Record the topology output and the current backup state, because restoring an outdated backup into an active replica topology can break replication. A healthy baseline is the output that closes this step, and it is the reference point for every later change. Confirm the procedure with your platform team, since the replica layout will shape how you stage changes.
Classify Linux assets by sensitivity
Work with asset owners to list the Linux hosts, services and administrative interfaces in scope, and assign each a classification tier that reflects the sensitivity of the data or function it supports. NIS2 implementing rules expect authentication strength to match the classification of the asset accessed, so this register is the input for every later decision. The output is a signed asset register with one owner per host, reviewed by the security function.
Define host groups and HBAC rules
Create host groups that mirror the classification tiers, then write host-based access control rules that name which user groups may log in to which host groups, and under what service. Remove the default allow-all rule once the explicit rules are tested with a non-production user. The check that closes this step is a test matrix showing each role can reach its permitted hosts and no others, with the results stored with the change record.
Set password and lockout policy
Configure password policies per group, covering change on first login, expiry intervals, history, minimum quality, and the failed-login threshold and lockout duration that block users after a predefined number of failures. Align the values with the policy your organization has approved, and confirm the exact attribute names against the current FreeIPA documentation for your version. The output is an exported policy set and a test showing that a locked account cannot authenticate until the defined reset occurs.
Enrol OTP for privileged and remote users
Enrol second-factor tokens for administrators and for anyone who logs in remotely, using software or hardware OTP tokens that FreeIPA supports. Require the second factor for privileged and system administration accounts, and for the host groups classified as high sensitivity. Record the token type, the enrolment date and the person it is linked to. The check is a successful and a failed login test for each group, with the results kept as evidence.
Separate administrative accounts from daily identities
Give each administrator a second, separate identity used only for privileged work, with its own credentials and OTP enrolment, and keep it out of everyday groups. Each identity should link to one named person. Shared identities should exist only where the owner has granted explicit approval, recorded with the reason and the approver. The output is a list of paired identities and a group membership report showing that privileged groups contain only the approved administrative accounts.
Configure sudo rules and review access rights
Write sudo rules that grant only the commands each role needs, applying need-to-know and least privilege, and remove any broad rule inherited from earlier configuration. Document separation of duties where one person must not both request and approve a change. Schedule access reviews at planned intervals, and define the steps for deactivating identities on termination or role change without delay. The closing evidence is an exported sudo rule set, a review record and a deactivation test showing a departed user loses access.
Capture evidence for each control
Assemble an evidence pack that maps each control to its configuration export, test result, approval record and review date, so that an inspector can trace a requirement to a working setting. Keep the exports versioned, and note the FreeIPA version and the date each export was taken. Confirm with your compliance lead which evidence format your national authority or auditor accepts, since NIS2 creates no certificate and the evidence is judged during inspections and audits.
What FreeIPA does not cover for NIS2
FreeIPA covers much of the identity and authentication work behind NIS2 Article 21(2)(i) and (j), but several obligations sit outside any directory service. The cards below mark the gaps your own programme has to fill, and the points to confirm with counsel and your national authority.
HR security and background verification
Annex point 10 of Implementing Regulation 2024/2690 covers background verification, termination procedures and disciplinary processes. FreeIPA can disable an account quickly, but it does not decide who should hold one. Your HR system must trigger joiner, mover and leaver changes, and you need records showing that screening happened before access was granted. Confirm with your HR and legal teams which roles require screening.
Physical access control
Point 13.3 of the Annex addresses physical access to facilities and equipment. FreeIPA controls logical access to Linux hosts and has no role in badge systems, door controllers or data hall entry. Keep physical access logs and their review under your facilities process, and make sure a physical access revocation is linked to the same leaver workflow that disables FreeIPA identities.
Secured voice, video and text communications
Article 21(2)(j) also asks for secured voice, video and text communications and secured emergency communication systems. Directory-based login does not secure a phone system, a conferencing tool or an out-of-band channel used during an incident. Identify these systems separately, confirm how their own authentication and encryption work, and decide how staff reach each other if the identity platform is unavailable.
Asset management beyond identity
Article 21(2)(i) and Annex point 12 expect a maintained asset inventory. FreeIPA lists enrolled hosts and their host groups, but it does not discover unmanaged devices, track hardware lifecycles or record software versions across the estate. Pair FreeIPA host data with a configuration or asset inventory tool and confirm that every server that accepts logins appears in it.
Incident reporting under Article 23
Article 23 sets reporting deadlines for significant incidents, and FreeIPA logs can support the timeline. The platform does not classify incidents, notify your national CSIRT or hold the reporting workflow. Decide who reports, which FreeIPA and Kerberos logs are retained for investigation, and how you will export them quickly during an incident.
Continuous authentication solutions
Article 21(2)(j) requires multi-factor or continuous authentication where appropriate. FreeIPA supports HOTP and TOTP tokens and can proxy OTP checks to RADIUS, but it does not score session risk or re-challenge users based on behavior. If you rely on continuous authentication for high-value assets, assess that requirement separately with your architects and security team.
The NIS2 risk assessment itself
Article 21 expects a risk-management approach built on an assessment of your own risks. FreeIPA is a control, not an assessment. Your risk register must justify why each authentication strength applies to each asset class, and it must show who approved the residual risk. Use the ENISA technical guidance to structure the evidence, and confirm the scope with counsel.
Pending changes to NIS2 obligations
The Commission proposed targeted amendments to NIS2 on 20 January 2026 (COM(2026) 13), including a new small mid-cap category. The proposal still needs approval by the European Parliament and the Council. Check whether your entity classification or obligations could change, and confirm the current position with qualified legal counsel before you set your scope.
Questions buyers ask before scoping NIS2 identity work
Can our internal team deploy FreeIPA for NIS2 access control without a partner?
Yes, a capable internal team can deploy FreeIPA, but the harder part is the governance work around it. FreeIPA is GPL-3.0-or-later community software with no paid edition, so the software cost is the cost of the people who install, operate and document it. The questions to settle honestly are whether your team has spare capacity for a multi-server build, whether it can keep up with security releases such as the 4.13.4 fixes, and whether it can produce the access register, review records and authentication evidence that Implementing Regulation 2024/2690 expects. Many teams split the work: internal staff own the platform and a partner covers the scoping, the control mapping and the evidence set.
What drives the effort of a FreeIPA NIS2 identity project?
Effort rises with the number of Linux hosts, the number of asset classes that need different authentication strength, and the identity sources you must replace or connect. Under the Implementing Regulation, authentication strength must match the classification of the asset accessed, so each asset class adds policy design and testing. Existing LDAP or Active Directory estates add migration and trust work, and sudo and HBAC rules need manual migration through LDIF. OTP token logistics also matter: issuing, enrolling, replacing and recording hardware or software tokens for every privileged and non-privileged user takes process design as well as configuration. Ask for the effort breakdown by these drivers in any written scope.
How long does a FreeIPA NIS2 identity engagement take?
Duration depends on the scope, so no general timeline applies. Most engagements are fixed-scope, which means the scope, deliverables and timeline are agreed in writing before work starts. Ask any provider to state the phases, the dependencies on your asset inventory and HR inputs, and the acceptance tests for each phase. Delays usually come from inputs outside the build, such as an incomplete asset list or slow approval of token procedures, so ask which of these you must supply and by when.
What does the client need to provide for a NIS2 identity build?
The work depends on your own records, so plan to provide several inputs before design starts:
- An asset inventory of Linux hosts and services, with a classification for each asset, since authentication strength must match that classification.
- Named owners for each asset class and each privileged or administrative account group.
- HR feeds covering joiners, movers and leavers, so access can change on termination or role change and identities can be deactivated without delay.
- Your current directory and sudo or access rules, including any shared identities and the approvals that cover them.
- A decision on token logistics, including who issues tokens and how lost tokens are handled.
Does FreeIPA alone satisfy NIS2 multi-factor authentication requirements?
No. FreeIPA is an identity and authentication platform, and it can support requirements for multi-factor authentication, credential changes, failed-login blocking and separate privileged credentials. However, NIS2 creates no certificate of compliance, and FreeIPA does not make an organization compliant. Article 21(2)(j) and the Implementing Regulation also require policies, asset management, human resources processes, physical access controls and evidence that the controls operate. Those come from your organization, and national authorities judge the whole system through inspections and information requests. FreeIPA covers part of the technical control set, and you should map each requirement to a control, an owner and a record.
What does post-deployment support look like for FreeIPA identity controls?
Post-deployment work usually covers operating the platform and keeping the evidence current. Ongoing support, upgrades and continuous testing are available as retainers, so the scope of recurring work can be agreed separately from the build. Typical items include applying security releases, reviewing the access register at planned intervals, checking backups, reviewing lockout and password settings, and handling token replacements and leavers. Ask whether support covers the replica topology, backup restore tests and the upgrade path between 4.x releases, and how evidence is produced for each review.
Who is responsible for the access register and periodic access reviews?
Your organization remains responsible for the access register and the review decisions, and FreeIPA can hold the underlying data. Access rights must follow need-to-know, least privilege and separation of duties, be recorded in a register and be reviewed at planned intervals. A partner can design the register structure, export reports from the directory and set up the review cycle, but managers and asset owners must approve access. Confirm during scoping which person signs each review and where the signed records are kept.
Are NIS2 identity controls in scope if we also use Active Directory?
Usually yes, and the scope needs an explicit decision. FreeIPA can establish a cross-forest trust with Active Directory through Samba components, but the IPA domain must use a DNS domain that does not overlap with any AD forest domain. Decide whether Windows users need access to Linux assets under the same policy, whether the trust is required, or whether identities will be migrated. Each choice changes the asset inventory, the token process and the evidence set, so raise it before estimating effort.
Where hosting and support access can change the picture
Where identity data and administrator sessions are hosted, and who can reach them from outside the EU, can change the compliance picture even when FreeIPA itself is open source and self-hosted. Under GDPR, every transfer of personal data to a third country, including onward transfers, must meet Chapter V conditions (Article 44). The EDPB's Guidelines 05/2021 state that remote access from a third country is a transfer, even when the person only views data on a screen for support or administration. FreeIPA directories hold user names, group memberships, host records and SSH keys, so a vendor engineer or an outside administrator connecting from abroad to troubleshoot Kerberos or replication may trigger those conditions.
The entity should confirm who holds administrative access to the FreeIPA servers, the Dogtag CA, and the backup files created by ipa-backup, and from which countries those sessions originate. Confirm where audit and access logs are written and where they are copied, since log stores often replicate to cloud regions. Ask any external support provider to state its remote access paths, whether it uses a jump host inside the EU, and whether any support staff sit outside the EEA. Record the answers in the access register that NIS2 requires for access rights.
If identity data or administrator access is handled by a provider subject to US law, assess the reach of the CLOUD Act at 18 U.S.C. 2713, which requires providers to preserve or disclose data in their possession, custody or control regardless of where it is stored. EDPB Recommendations 01/2020 also note that where public authority powers go beyond what is necessary and proportionate, no effective technical supplementary measure may be available. Document this assessment before engaging a support partner, and confirm with the partner how it would respond to a foreign disclosure request. EDPB Recommendations 01/2020 sets out the test to apply.
How DeployOpen scopes NIS2 access control work on FreeIPA
DeployOpen plans, implements, hardens, documents and supports FreeIPA inside your own infrastructure, including its cloud accounts, data centers or air-gapped networks. For NIS2 multi-factor authentication and access control, the work starts with a written scope that maps your Linux estate to the access control and authentication requirements your authorities will examine.
How we scope
- Inventory Linux hosts, services and privileged accounts that fall under your NIS2 access control policy
- Agree in writing which MFA methods, OTP or certificate-based options, cover each asset class
- Define which evidence artifacts the written scope delivers and which your compliance team owns
How we build
- Configure FreeIPA password, lockout, OTP and host access policy in a non-production environment first
- Test MFA enrollment, failed log-in lockout and session termination against the agreed scope
- Document each configured control with its owner, review interval and the test that verifies it
How we hand over
- Deliver configuration records, runbooks for joiner, mover and leaver processes and access register exports
- Walk your operations and security staff through privileged account separation and recovery steps
- Provide written test results and a list of open items, with owners agreed before handover
How we support
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts
- Ongoing support, FreeIPA upgrades and continuous testing are available as retainers
- Confirm with your legal and compliance advisers which obligations apply to your entity and sector
