Why FreeIPA fits energy and utilities Linux estates
FreeIPA can give a utility or generator centralized Linux identity, Kerberos single sign-on, host access policy and certificates on servers the operator controls, including inside segmented operational technology adjacent networks. Its components are 389 Directory Server for users, groups, hosts and policies, an MIT Kerberos KDC for single sign-on, the Dogtag certificate authority, and SSSD on each client. Because all of these run on your own machines, the identity service does not depend on a vendor cloud or on a connection to a corporate directory across the network boundary.
The design change that matters most is local continuity. Place replicas at each site where Linux hosts must still authenticate when a WAN link or a corporate domain controller is unavailable, and confirm that SSSD caching and offline login behave as you expect on each host class you run. Admin access is the other change: FreeIPA supports HOTP and TOTP tokens, including hardware keys, and can proxy OTP checks to an existing RADIUS server, so multi-factor authentication for privileged sessions can be designed into the identity layer. Confirm with your own engineers which of these paths your interactive remote access must pass through.
Set expectations early with compliance and operations. NERC CIP obligations depend on how your entity classifies its BES Cyber Systems under CIP-002 and which Applicable Systems each requirement covers, not on the identity product you choose. FreeIPA can support controls such as access management and authentication evidence, but it does not make a system compliant, and an independent Compliance Enforcement Authority decides what evidence is sufficient. Ask your compliance lead to map each identity control to the specific CIP requirements that apply to your assets before design starts.
Which energy sector requirements shape the FreeIPA design
This table maps each energy-sector requirement to what it asks for and what it changes in a FreeIPA build, covering replicas, MFA and access logs. Read each row as a design input: the requirement sets the boundary, and the consequence column shows where FreeIPA settings and topology must follow. Confirm applicability with your compliance lead and the registered entity's impact classification before fixing the design.
| Requirement | What it asks for | Consequence for the FreeIPA build |
|---|---|---|
| CIP-002-5.1a impact classification | Sorts BES Cyber Systems into high, medium or low impact using bright-line criteria in Attachment 1 | Decide first which systems and hosts run the IdM servers and clients. Higher impact classes usually justify more replicas per site and stricter access logging on the servers themselves. |
| CIP-005-7 Electronic Security Perimeter | Routable-connected assets of high and medium impact systems sit inside an Electronic Security Perimeter | Place IdM servers and replicas inside the perimeter. Replication and LDAP or Kerberos traffic crossing the boundary must be listed and justified. |
| CIP-005-7 Interactive Remote Access | All interactive remote access passes through an Intermediate System with encryption and multi-factor authentication | Require OTP or another second factor for remote administrative logins to hosts that rely on FreeIPA. Confirm with the vendor which MFA paths your SSH and sudo setup actually enforces. |
| CIP-013-2 vendor remote access and software integrity | Supply chain plans cover vendor notification, software integrity verification and coordinated vendor-initiated remote access, reviewed at least every 15 calendar months | Track FreeIPA package sources, signed updates and upgrade records. Vendor accounts that reach the environment need their own FreeIPA identities, group membership and expiry dates. |
| CIP-011-3 information protection | Protects BES Cyber System Information, including access controls and handling of stored information | Restrict who can read directory data, keytabs and backups. Encrypt backup archives, control who can run ipa-backup, and log restores. |
| NIS2 Annex I energy scope (EU operators) | Electricity, district heating and cooling, oil, gas and hydrogen are high-criticality sectors | Operators in these subsectors should confirm their national transposition and risk obligations. The identity design should document access controls and logs that support incident reporting. |
FreeIPA modules and settings that matter for OT-adjacent hosts
Most of the FreeIPA design work for OT-adjacent estates sits in a handful of settings: where replicas live, how hosts keep working offline, how administrators prove who they are, and who may log in to which hosts. Each card names one decision and the check that confirms it before a substation or plant host depends on it.
Replica layout per site
The deployment recommendations advise at least two to three replicas in each datacenter and no more than four replication agreements per replica. For energy estates, plan replicas per control center, substation aggregation point or generation site so that a WAN outage does not strand local hosts. Keep at least one replica per site running PKI or DNS if you use them, and run the servers on dedicated hosts. Confirm the topology with the replication commands before any segment is cut off.
SSSD offline login on field hosts
Substation and plant hosts often lose the path to IdM servers during faults or maintenance. SSSD caches credentials and group data so that known users can still log in. Decide which accounts must work offline, test a login with the IdM servers unreachable, and document how long cached credentials remain valid under your settings. Treat offline access as a deliberate exception that your compliance team reviews, not a default that nobody checked.
OTP and RADIUS for administrative MFA
FreeIPA supports HOTP and TOTP tokens, including hardware tokens such as YubiKeys, and can proxy OTP checks to an existing RADIUS server. For administrative access into BES Cyber System hosts, confirm which factor each administrator uses, how tokens are issued and revoked, and whether the RADIUS path is reachable from the segment where administrators connect. Test the full sudo and SSH flow from the intermediate system you actually use, because MFA that fails during an outage forces staff toward shared accounts.
HBAC and sudo scoped to BES Cyber hosts
Host-based access control and sudo rules should follow the impact classification of each host, not the org chart. Create host groups for high, medium and low impact systems, then grant login and sudo only to the user groups that operate them. Remove default allow rules that reach every enrolled host, and review rules after each asset change. Confirm the mapping from CIP-002 classifications to host groups with the people who maintain the asset inventory.
Certificate issuance and renewal ownership
The first FreeIPA server handles certificate renewal and CRL publication by default, so an unplanned outage of that host can stop renewals silently. Assign a named owner for the Dogtag certificate authority, document which services hold certificates, and monitor expiry dates for host and service certificates used by SCADA, historian and intermediate systems. Confirm that the renewal owner is also on the change log for any server move or replacement.
Backup and restore cautions
ipa-backup offers full and online data-only backups, but the backup documentation warns that restoring an outdated backup into an active replica topology can break replication. Store backups off the replica hosts, record which server each backup came from, and rehearse restores in an isolated environment before relying on them. Ask the vendor or your team to confirm the restore order for your topology, because a restore that works on one server can damage the replicas that still hold newer data.
How replicas and DNS work across control centers and plants
The control center enclave usually holds the most sensitive administrative paths into operational systems, so it is the natural home for the primary identity servers. Place these servers inside the enclave boundary your team defines for CIP-005-7 and confirm with your CIP-002 categorization whether the identity servers are themselves in scope. The FreeIPA deployment recommendations describe the replica layout that the enclave design should start from.
- Replica count: Plan two to three replicas in each datacenter, on dedicated servers that run no other applications.
- Replication agreements: Keep no more than four replication agreements per replica so the topology stays within the recommended limit as sites are added.
- PKI and DNS placement: If the enclave runs certificate authority or DNS services, place at least one replica running them in each datacenter.
- Renewal ownership: The first server handles certificate renewal and CRL publication by default. Decide which enclave server holds that role, and back it up on a schedule your team can prove.
- Restricted material: Keep backup archives and CA key material inside the enclave. Restoring an outdated backup into an active replica topology can break replication, so restores need a controlled procedure.
Confirm the enclave boundary, the in-scope asset list and the replica placement against your own network diagrams before the first server is installed.
A generation plant or substation often has a narrower network path back to the control center, and its local systems may need to keep authenticating when that path is degraded. Whether a site hosts its own replica depends on its size, its connectivity and whether it qualifies as a datacenter in your design. Every enrolled client at the site still needs DNS and Kerberos reachability, so the site design has to answer where its clients resolve names and where their tickets are issued.
- Two DNS servers per client: Configure at least two DNS servers in each client's resolv.conf. If the site has only one local resolver, a single failure can stop name resolution for every client there.
- Local replica decision: Evaluate a site replica against the recommended two to three replicas per datacenter. A site that is not a datacenter may rely on replicas in the control center, so confirm the latency and failover behavior of that path.
- Certificate renewal path: Confirm which server a site client reaches for certificate operations and whether that server stays reachable during a WAN outage.
- Vendor and remote access: Do not let identity services become a route around the controls that govern interactive remote access. CIP-005-7 requires that interactive remote access pass through an Intermediate System with encryption and multi-factor authentication.
- Low impact status: If the site is classified as low impact, check the vendor electronic remote access controls introduced by CIP-003-9, which became enforceable on 1 April 2026.
Confirm the site classification, the client DNS list and the outage behavior with your plant engineers and compliance lead before finalizing the site design.
Operators in EU jurisdictions, and remote operators who reach systems across borders, add two concerns: where identity data is held and which paths external users can reach. NIS2 Annex I lists energy as a sector of high criticality, and Commission Delegated Regulation (EU) 2024/1366 sets a network code for cybersecurity rules on cross-border electricity flows. Which obligations apply to a given entity depends on its national transposition and regulator, so confirm them locally before fixing the replica and DNS layout.
- Replica location: Place at least one replica per datacenter in the jurisdiction where the sessions terminate, and confirm with counsel and the regulator where identity data may be stored and processed.
- Resolver reach: Point remote operator clients at the DNS servers inside the controlled path, and keep the client rule of at least two DNS servers in each resolv.conf.
- PKI and revocation: Decide whether remote operator certificates come from the same CA as the enclave. CRL publication runs from the first server by default, so the CRL must stay reachable to the systems that check it.
- Exposure limits: Do not expose the directory, Kerberos or CA services directly to the internet. Replication and administration should travel only over approved links.
- Vendor paths: Coordinate any vendor-initiated remote access with the supply chain plan that CIP-013-2 requires, reviewed at least every 15 calendar months.
Confirm the applicable NIS2 and cross-border obligations, the replica jurisdictions and every external path against your own network diagrams and legal review.
Rollout phases for a FreeIPA build in a regulated utility
The sequence moves from impact classification to a tested, evidenced and recoverable identity service, so each phase gives the compliance and operations teams something to check before the next one starts. Phase timing and exit criteria are fixed in the written scope, not on this page.
Confirm scope and impact classification
Before any server is built, the utility's CIP compliance lead and DeployOpen agree which assets are in scope and how each one maps to the CIP-002 impact categories (high, medium or low) using the bright-line criteria in that standard's attachment. The team lists the BES Cyber Systems, the associated EACMS and PCA, and the Interactive Remote Access paths that FreeIPA will touch, and confirms which Applicable Systems tables apply. The step closes with a signed scope document and an asset list that the compliance team has reviewed. Confirm with your Compliance Enforcement Authority contact how they expect the classification to be documented.
Build the test realm and replica design
DeployOpen stands up a non-production IdM realm that mirrors the planned topology, including replicas per site, the placement of CA and DNS services, and the segmented network paths between control zones and the corporate side. The team tests replication limits, DNS resolution from isolated segments and the behavior of the first server, which handles certificate renewal and CRL publication by default. The step closes when replication is verified across every planned link and a recorded topology diagram has been approved by operations and security.
Enroll pilot hosts and verify offline login
A small set of non-critical pilot hosts in a test zone is enrolled with SSSD, and the team checks host access rules, sudo policy and SSH key distribution against the approved access model. Because operational systems must keep working during an outage, engineers disconnect the pilot segment from the directory and confirm that cached logins still succeed for authorized accounts. The step closes with a pilot report listing each host, the policy tested, and every failure found and corrected.
Cut over MFA and remote administrative access
Administrative and remote access paths are moved to FreeIPA with multi-factor authentication, using the OTP tokens and any RADIUS proxy the design calls for, and every path that reaches a BES Cyber System is routed through the Intermediate System required by CIP-005. Engineers verify that token enrollment, lockout behavior and recovery procedures work for named administrators, and that break-glass accounts are documented and tested. The step closes when each remote path has been exercised with MFA in a change window and the results are filed with the change record.
Capture evidence for compliance
DeployOpen and the utility's compliance team define which records the CIP audit team will ask for, such as access list changes, MFA enforcement settings, audit log exports and vendor remote access records, and configure collection so that each one can be produced without manual reconstruction. The team confirms with the compliance function that the evidence matches the requirement tables it applies to. The step closes with an evidence index that maps each control to a repository location, an owner and a sample export. There is no CIP certificate, so the index supports the audit rather than replacing it.
Test backup, restore and recovery
The team runs ipa-backup on a live server, restores into an isolated environment, and tests recovery from the loss of the first server and from an outdated backup, since the backup documentation warns that restoring an outdated backup into an active replica topology can break replication. Operations staff practice the runbook so that they can rebuild a replica and re-issue certificates without vendor involvement. The step closes when a restore test has been completed, timed and signed off by operations, and the runbook is stored with the evidence index.
Hand over to operations with a review cycle
The final step transfers ownership of the FreeIPA servers, health checks, patch process and access review tasks to the utility's operations team, with DeployOpen providing the documentation and a handover session. The team agrees a recurring review of the scope document, the CIP-013 vendor risk items where FreeIPA support is involved, and the evidence index. Any ongoing support, upgrade or testing work beyond handover is set out as a separate retainer or written scope. The step closes with a signed handover record and a schedule of the first operational review.
What FreeIPA can and cannot prove for NERC CIP
FreeIPA can produce configuration and log evidence that supports several CIP requirements, but no product certifies CIP compliance. The cards below separate what an auditor can be shown from what remains a decision for your compliance team, counsel and the Compliance Enforcement Authority.
No CIP certificate exists
NERC does not issue a CIP certificate. The Compliance Enforcement Authority, a Regional Entity or NERC, monitors compliance through Compliance Audits, Spot Checks, Self-Certifications, Self-Reports and periodic data submittals. For FreeIPA, this means the question is never whether the directory is certified, but whether your records show that access controls were configured, applied and reviewed for the systems in scope. Confirm with your Regional Entity which evidence formats it accepts.
FreeIPA supplies supporting evidence
FreeIPA can export its access policy, host-based access control rules, sudo rules, group membership and audit logs. These support requirements on authentication, access management and monitoring for the Cyber Assets it actually manages. They do not cover devices outside its enrollment, physical access systems or vendor remote sessions, which need their own records. Map each CIP requirement to the specific FreeIPA object or log that supports it before the audit window opens.
CIP-003-9 enforceable since April
CIP-003-9 adds vendor electronic remote access controls for low impact BES Cyber Systems and became enforceable on 1 April 2026. If your low impact assets allow vendor remote access, the access path and its authentication need documented controls. Ask whether any vendor accounts will be held in FreeIPA or in a separate identity source, and who approves and removes them.
CIP-012-2 enforceable since July
CIP-012-2 adds protection of the availability of Real-time data between Control Centers and became enforceable on 1 July 2026. Identity services that authenticate the systems exchanging that data sit in scope for availability planning. A FreeIPA replica that fails during a control center event could block logins, so confirm replica placement and failover with your operations team and the standard text.
CIP-015-1 and CIP-015-2 future monitoring
CIP-015-1 covers internal network security monitoring and is enforceable from 1 October 2028. CIP-015-2 extends monitoring to associated EACMS and PACS and has an effective date of 1 October 2029. FreeIPA authentication logs, including failed logins and sudo activity, are likely inputs to that monitoring, but they are not a monitoring system on their own. Plan log forwarding to your security monitoring platform now so the feed exists when the requirement applies.
Penalty exposure and final determination
The maximum civil penalty is $1,584,648 per violation per day, according to 18 CFR 385.1602. Whether a given FreeIPA setting satisfies a requirement depends on your impact classification under CIP-002, your asset scoping and your Regional Entity's interpretation. Engage counsel and your compliance auditors for the final determination before relying on any design in an audit.
What utilities ask before hiring a FreeIPA partner
What drives the cost and effort of a FreeIPA build for a utility?
The biggest drivers are how many sites and network zones need local identity, how many Linux hosts must enroll, and how many of those hosts fall under CIP scoping. Each replica, certificate authority choice, DNS design and MFA integration adds design and test work. Quotes are fixed-scope, so ask for the written scope to list the sites, host counts, integrations and documentation deliverables it covers. One-time costs are the design, build, testing and handover. Recurring costs are your staff time for patching, backups and access reviews, plus any retainer you choose for support or upgrades. DeployOpen does not publish a price list, so the quote follows from that scope.
How long does a FreeIPA build take, and what sets that duration?
Duration depends on the number of control center and substation zones, the replica layout, how many hosts must enroll, and how many approval windows your change process requires. Work that touches operational technology networks usually moves at the pace of your change windows and outage approvals, not the install itself. The deployment recommendations advise at least two to three replicas in each datacenter, which sets the minimum server count per site. Ask for a timeline in the written scope that shows which phases depend on your approvals, and confirm which environments need test copies before production.
What must our utility provide before the engagement starts?
Plan to supply the inputs an assessor and an engineer would both need before any server is built:
- Network diagrams showing segments, routed paths and where any Electronic Security Perimeter boundary sits
- Current BES Cyber System impact categorization and the asset lists behind it
- Named owners for identity, DNS, certificates and OT change approval
- Maintenance windows and rollback rules for each site
Also confirm which hosts are in scope for remote access, since CIP-005-7 requires Interactive Remote Access to pass through an Intermediate System with encryption and multi-factor authentication. Your compliance team should confirm the exact applicability of each standard with NERC or the Regional Entity.
Can our internal staff run FreeIPA after handover?
Yes, if the handover includes the runbooks, the topology record and training for the people who will operate it. Your staff will need to handle client enrollment, user and host policy changes, certificate renewal checks, backups and health checks. The backup documentation warns that the first server handles certificate renewal and CRL publication by default, so operators must know which server that is. Ask for documented procedures, a test restore record and a named list of operator responsibilities in the written scope. DeployOpen also offers ongoing support and upgrades as retainers if your team wants help after handover.
How do upgrades and security releases like 4.13.4 affect a regulated estate?
Security releases change the change-management workload, not just the software. FreeIPA 4.13.4, dated July 9, 2026, fixed two CVEs, including LDAP access control flaws that could let unauthenticated clients obtain credentials, and it hardened authentication checks across the API. Treat such releases as a documented change: assess exposure, test in a non-production topology, schedule within your windows and record the evidence. Upgrades to a new minor line, such as the 4.13.0 changes to the web UI and DNS over TLS, need a separate review of client and DNS behavior. Confirm your vendor patch intake and emergency change path before the first release arrives.
How are backups and recovery tested for a utility deployment?
Test restores on a separate topology, not just a successful backup job. FreeIPA provides ipa-backup and ipa-restore, with full backups or online data-only backups. The backup documentation warns that restoring an outdated backup into an active replica topology can break replication, so a recovery test should prove the restore order, the replica rebuild steps and the certificate state afterward. Record the recovery time you actually observed in a test, and retain the evidence for your CIP-009 recovery plan. Ask the partner to show that test in the written scope.
Does FreeIPA support MFA for administrative access on our isolated networks?
FreeIPA supports two-factor authentication with HOTP (RFC 4226) and TOTP (RFC 6238) tokens, including software tokens and hardware tokens such as YubiKeys, and it can proxy OTP checks to an existing RADIUS server. Whether that satisfies a specific CIP-005-7 requirement depends on where your Intermediate System sits and how administrative sessions traverse the perimeter. Confirm with your compliance team and assessor how the MFA control maps to your environment, and confirm which hardware tokens your procurement will accept before the design is fixed.
Does a FreeIPA deployment make us CIP compliant?
No. Compliance is a property of your whole program, and there is no CIP certificate. NERC and the Regional Entities monitor compliance through Compliance Audits, Spot Checks, Self-Certifications and other methods, and entities registered as a Balancing Authority, Reliability Coordinator or Transmission Operator receive a compliance audit at least once every three years. DeployOpen prepares systems, controls and evidence for compliance assessments, but does not issue audit reports or certifications. Independent assessment and your Compliance Enforcement Authority decide the outcome.
What to ask a partner before signing a FreeIPA scope
Start with the network. Ask the partner to describe, in named engagements they can talk about without identifying clients, how they have deployed FreeIPA servers and SSSD clients into segmented OT-adjacent networks, including where replicas sat relative to the Electronic Security Perimeter and how client enrollment crossed the boundary. Ask how they would place at least two to three replicas in each datacenter, which systems would run PKI or DNS, and how they would confirm that clients still authenticate when the upstream network is cut. A partner who answers with generic enterprise examples has not yet thought about your segmentation.
Next, ask how they will handle the first server. By default the first server in a FreeIPA topology handles certificate renewal and CRL publication, so the scope should name which server holds that role, how it is monitored, and what happens if it fails. Ask them to show the procedure for moving that duty to another replica and to explain how they test restores. The backup documentation warns that restoring an outdated backup into an active replica topology can break replication, so ask for the restore test plan in writing, including whether it runs on an isolated copy and how the result is checked against the live topology before anything is returned to service.
Finally, require the written scope to define evidence. Ask which records the partner will produce for each control your compliance team relies on, such as access reviews, MFA enrollment for administrative accounts, backup and restore test records, and change logs, and who keeps them after handover. Confirm the boundary too. DeployOpen prepares systems and evidence for assessments but does not issue audit reports or certifications, so compliance determinations for NERC CIP and any other framework remain with your compliance function and the auditors it engages. Your team also keeps ownership of the Compliance Enforcement Authority relationship, the asset classification under CIP-002, and the operating procedures that people follow day to day.
How DeployOpen scopes and delivers FreeIPA for utilities
DeployOpen plans, implements, hardens, documents and supports FreeIPA on servers you control, including in segmented or offline networks. Engagements are fixed-scope, with scope and deliverables agreed in writing before work starts, and ongoing support is available as a retainer.
How we scope
- Inventory which Linux hosts sit in OT-adjacent zones and which carry administrative access paths
- Map each zone to its FreeIPA replica, DNS and certificate locations before any server is built
- Record which logins must keep working when the WAN or upstream directory is unavailable
- Agree in writing the in-scope sites, host counts, MFA method and evidence deliverables
How we build
- Deploy replicas per site and document replication agreements, following the vendor's topology recommendations
- Configure SSSD offline login, HBAC and sudo rules that match the access model agreed in scope
- Set up MFA for administrative access using OTP tokens or a RADIUS proxy, and test lockout and recovery paths
- Test backup, restore and replication behavior in a lab before the production cutover
How we hand over
- Provide configuration documentation, runbooks and an access control matrix mapped to the agreed scope
- Deliver evidence of access reviews, MFA enforcement and logging so your compliance team can review them
- Train operators on backups, certificate renewal, replica recovery and onboarding of new hosts
- Hand over administrative credentials and backup keys under a documented custody procedure
How we support
- Offer retainers for patching, upgrade planning and review of FreeIPA security releases
- Plan upgrades in a staging topology first, confirming compatibility with your OT change windows
- Review access policy changes and host enrollment requests against your documented control set
- Confirm with your compliance advisers which controls they will assess before relying on DeployOpen documentation
