FreeIPA for manufacturing and isolated networks

Why FreeIPA fits isolated plant networks and what changes

A plant or engineering team that needs central Linux identity on a segmented network with limited or no internet access can run FreeIPA entirely inside the plant boundary. The design shifts from an internet-connected office deployment toward local replicas, local certificate authority operation and login that keeps working when the link to corporate systems is down. FreeIPA combines 389 Directory Server, MIT Kerberos, the Dogtag certificate system and SSSD on clients, so the identity store, ticketing and certificates can all live on servers you control. FreeIPA is GPL-3.0-or-later community software with no paid edition of its own, so there is no vendor feature gate to check for air-gapped use. The cost is the work itself: architecture, build, hardening, backup and ongoing operation are yours to plan, whether you staff them internally or contract them out. Confirm early which decisions your plant standards and your existing OT security program require you to document, because they determine the design more than the software does.

Compared with an office deployment, three things change. First, replica placement follows the network zones: the deployment recommendations advise at least two to three replicas in each datacenter and at least one replica per datacenter running PKI or DNS if you use them, so each plant zone needs its own local servers rather than a single remote hub. Second, the certificate authority has to operate without outside connectivity. Plan which server handles certificate renewal and CRL publication, since the backup documentation notes that the first server does this by default. Third, clients must authenticate offline. Confirm how SSSD caches credentials on shop floor machines and test logins with the uplink cut, because a plant login that depends on a reachable server is a production risk. Updates also change shape. Packages and FreeIPA releases must be verified and carried across the boundary, and restoring an outdated backup into an active replica topology can break replication, so restore procedures need to be rehearsed in the isolated environment. Ask any partner to show a written plan for these three areas before the build starts.

Which industrial requirements shape the FreeIPA build

This table maps the industrial, operational technology and EU or US rules most often raised for plant networks against what each one means for a FreeIPA build. Read it as a list of questions to confirm with your compliance and OT teams, because some rules bind asset owners, some bind product suppliers and some may not apply to your sites at all.

Requirement	What it asks for	What it means for the FreeIPA build
ISA/IEC 62443 series (ISA)	Organizes security for industrial automation and control systems into general, policy and procedure, system and component groups	Defines the zone and conduit model you will map FreeIPA servers and clients into, and tells you which parts of the series apply to your role as owner or supplier
ANSI/ISA-62443-2-1-2024 (ISA)	Security program requirements for IACS asset owners	Expect to document who administers identity on the plant side, how accounts are reviewed and how identity services are covered by the site security program
ANSI/ISA-62443-3-2-2020 (ISA)	Security risk assessment for system design	Use the zone design output to decide where replicas sit, which zones can reach a replica and which must rely on local replicas only
ISA-62443-3-3-2013 (ISA)	System security requirements and security levels	Confirm the target security level per zone with your OT team, then set FreeIPA authentication, password and access controls to match it
ANSI/ISA-62443-4-1-2018 and 4-2-2018 (ISA)	Secure development lifecycle and technical requirements for component suppliers	Mainly relevant to vendors of shop floor equipment. Ask suppliers whether their systems can use SSSD or Kerberos from FreeIPA and what they document
NIST SP 800-82 Rev. 3, September 2023 (NIST)	OT security guidance covering SCADA, DCS, PLCs and physical access control, with performance, reliability and safety requirements	Plan identity services so that authentication never blocks control operations, and test local login behavior before any change to replicas or certificates
NIS2 Annex II, manufacturing (Directive (EU) 2022/2555)	Lists manufacturing divisions 26 to 30 and medical devices as a critical sector	If you are in scope, incident reporting runs on fixed clocks: early warning within 24 hours, notification within 72 hours and a final report within one month (Article 23(4)). Keep FreeIPA audit logs and replica status available to meet those clocks
Cyber Resilience Act (Regulation (EU) 2024/2847)	Essential requirements for products with digital elements, with manufacturer reporting duties for actively exploited vulnerabilities from 11 September 2026 (Article 71(2))	Applies to products you place on the market, not your internal identity service. Use it to decide which vendor products you accept and how you track their vulnerability notices
Machinery Regulation (Regulation (EU) 2023/1230), Annex III 1.1.9	Applies from 14 January 2027 and requires machinery to resist hazardous states when another or remote device connects	Ask machine builders which remote access and login paths they support, and avoid designs where a central identity outage would leave machines in an unsafe state
NERC CIP-013-2 (where relevant)	Supply chain processes must cover verification of vendor software integrity and authenticity, including patches	Applies if you operate bulk electric system assets. Use it as the model for verifying every package, signature and container image before it crosses an isolated boundary into FreeIPA

Which FreeIPA modules and settings matter on the shop floor

Plant and engineering networks depend on a few FreeIPA settings more than on any feature list. The cards below cover where servers sit, how clients find them, what the first server controls, how administrators authenticate and what happens to shop floor logins when the link to the rest of the network fails.

Replica placement per site

Plan at least two to three replicas in each datacenter, and treat a plant or engineering network as its own site when it has a separate link to the rest of the estate. Keep no more than four replication agreements per replica so the topology stays manageable as sites are added. Confirm where each replica sits relative to segmented zones, and whether a plant replica can keep serving logins during a WAN outage. Dedicate the servers to FreeIPA rather than sharing them with other applications.

DNS and resolv.conf for the plant zone

Each client's resolv.conf should list at least two DNS servers, and at least one replica in each datacenter should run DNS if you use IdM DNS. For a plant zone, check that the plant replica answers for local hosts even when upstream links are down. Confirm that clients in the segmented network can reach those DNS servers without routing through the corporate zone. A misconfigured resolver is the most common reason shop floor machines fail to find the KDC.

First server holds renewal and CRL

By default, the first server in the topology handles certificate renewal and certificate revocation list publication. In an isolated network, that role decides which server must stay reachable for certificate maintenance, so put it where administrators can reach it on the plant network. Before any restore, remember that restoring an outdated backup into an active replica topology can break replication. Record which server holds this role in your runbook and confirm the failover steps with your own environment before you need them.

OTP and RADIUS for admin access

Administrative access from engineering workstations should use a second factor. FreeIPA supports HOTP and TOTP tokens, including hardware tokens such as YubiKeys, and can proxy OTP checks to an existing RADIUS server if your plant already runs one. Decide which administrative paths need the second factor and test that logins still work when the RADIUS server or token service is unreachable. Keep emergency access documented and confirm it with your own change control process.

SSSD offline login on shop floor systems

SSSD caches credentials so that enrolled Linux systems can keep authenticating users when no FreeIPA server is reachable. On shop floor machines, verify the cache settings, the credential lifetime and which accounts can log in offline before you roll out. Test a full cycle with the plant link cut, including a password change made on a different host, because the cached state can differ from what administrators expect. Machines that control equipment should also have a local break-glass account that does not depend on any directory.

AD trusts only with a corporate domain

Build an Active Directory trust only when the plant must share identities with a corporate AD forest. The IPA domain must use a DNS domain that does not overlap with any domain in the AD forest, so plan the naming before installation because changing it later is expensive. If no corporate domain needs to be trusted, leave the trust out and keep the plant directory independent. Confirm the trust type and ID mapping with your own AD team before any work starts.

How the plant zone, DMZ and corporate network split the identity design

A fully air-gapped cell is a closed identity domain. Its FreeIPA servers, clients and DNS live inside the cell, and nothing in the cell depends on corporate services or the internet to authenticate a user. The deployment recommendations call for at least two to three replicas in each datacenter, so a cell that runs without any link to the rest of the estate still needs its own redundant replicas on dedicated servers.

Replica placement: Place two or three replicas inside the cell, keep each replica to no more than four replication agreements, and keep at least one PKI or DNS-capable replica if those services are used.
Client DNS: Point every client at two or more IdM DNS servers in resolv.conf, and confirm that those servers are the only resolvers the cell can reach.
Updates: Bring FreeIPA and operating system packages in on approved media after checksum and signature verification, and test them on a non-production replica first.
Certificates: The first server handles certificate renewal and CRL publication by default, so confirm that renewal schedules and CRL locations work with no outside connection.
Trust boundary: The cell boundary is the IPA domain itself. Do not configure trusts to Active Directory or external identity providers inside the cell unless you document that the boundary crosses them.

Confirm with your OT security team which package sources and media the cell can accept, and where backups go when they leave the cell.

In a segmented plant network, the plant zone holds the FreeIPA replicas that shop floor clients use, and a controlled DMZ sits between the plant and corporate networks. The DMZ is where data crosses the boundary, so it should carry only the traffic the design requires. Plant clients keep local authentication and DNS when the DMZ or the corporate link is unavailable, provided the plant-zone replicas are complete.

Replica placement: Put the plant-zone replicas on dedicated servers in the plant zone. Limit replication traffic between zones to the hosts and ports your firewall rules allow, and confirm that no replica depends on a DMZ host to stay online.
Client DNS: Plant clients resolve through plant-zone IdM DNS servers, with at least two listed in resolv.conf. If you plan to use DNS over TLS between clients and IdM DNS, confirm the release supports it and test that path through your segmentation.
Updates: Receive vendor packages on a staging host in the DMZ, scan and verify them there, then move them into the plant zone through an approved transfer method that your supplier verification process covers.
Certificates: Keep the CA in the plant zone. Confirm which server handles renewal and CRL publication, and approve certificate requests from DMZ systems before they reach the CA.
Trust boundary: The plant zone is the identity boundary. Any LDAP link to a corporate FreeIPA deployment, including an ipa-migrate run, is a conduit through the DMZ and needs its own rule set and review.

Confirm which zone your first server sits in, and who can change the firewall rules that govern replication.

How a plant FreeIPA rollout runs from zone design to offline operation

The sequence moves from agreeing which zones and identities are in scope to a plant identity service that keeps authenticating when the upstream network is cut. Each step produces a document or a tested result that the next step depends on.

Agree zone and identity scope
DeployOpen works with your OT, IT and engineering leads to map which network zones, machine types and user populations will authenticate against FreeIPA, and which will stay on local accounts. You provide the zone diagram, the list of shop floor and engineering systems with their operating systems, and the groups that need access. The step closes with a signed scope register that names every system in scope and the owner of each identity source.
Fix DNS and realm naming
The team sets the Kerberos realm and IPA DNS domain, decides whether DNS is served inside each plant zone, and records how clients will find servers when the corporate resolvers are unreachable. You confirm naming rules with your corporate directory team, since a domain that overlaps with an existing Active Directory forest causes trust problems later. The deliverable is a naming and DNS design note that the replica and client steps reference.
Place replicas in each zone
DeployOpen maps replica placement against the zone design, following FreeIPA's deployment recommendations for multiple replicas per datacenter and no more than four replication agreements per replica. Each plant that must authenticate during a WAN outage receives a local replica or receives a replica that can serve it. You provide hardware or virtual host capacity inside each zone and firewall rules that allow only the required replication and client ports. The output is a topology diagram and a replication check showing all agreements healthy before cutover.
Choose the certificate authority model
The team decides whether the integrated Dogtag CA runs on the first servers, and how it will issue certificates with no internet path to a public CA or to an external revocation endpoint. Renewal, CRL publication and the server that owns them are documented, because FreeIPA's backup guidance notes the first server handles these tasks by default. You confirm your internal PKI policy and any offline root requirements. The deliverable is a CA decision record with certificate profiles and a renewal calendar owned by named staff.
Enroll clients and test SSSD offline
Shop floor and engineering Linux systems are enrolled with SSSD configured for cached credentials, then tested with the upstream network disconnected to confirm local and domain users can still log in. Your engineers select a representative set of machines, including HMI and engineering workstations, and run the test scripts while the zone is isolated. The step closes when each machine class has a recorded offline login result, including the cache lifetime and the access rules that apply during the outage.
Set intake for packages and updates
Because the plant network cannot pull packages directly, DeployOpen defines how packages, FreeIPA updates and vulnerability feeds are fetched outside the boundary, scanned, and carried in on approved media or through a controlled repository. You provide the change approval path and the owner who signs off each intake. The deliverable is a written intake procedure with checksum verification steps, so every item crossing the boundary has a recorded origin and integrity check.
Rehearse backup and restore
DeployOpen runs ipa-backup on the production servers and restores the backup into an isolated test replica, then confirms that users, hosts, certificates and client logins behave as expected. The rehearsal also tests the warning in the backup documentation about restoring an outdated backup into an active topology, so the team learns the correct recovery order before it is needed. You schedule the rehearsal window and approve the test plan. The output is a restore runbook and a recorded rehearsal result.
Hand over for offline operation
DeployOpen walks your operations, security and OT staff through the runbooks, the health checks, the offline login procedure and the intake process, then confirms each named owner can perform them alone. Open items are logged with owners and due dates set by you. The handover is complete when your team has performed one supervised patch intake and one restore test without DeployOpen operating the system, and the documentation pack is accepted in writing.

How SSSD offline login keeps shop floor systems working

When a plant loses its connection to the FreeIPA replicas, SSSD offline login is what lets operators still sign in to shop floor Linux systems that were previously enrolled. SSSD on each client keeps a local cache of the account and credential information it has already retrieved, so login can succeed without reaching the directory. That cache covers only identities that have logged in or been looked up on that machine before. A new hire, a contractor added during an outage, or a password changed on another site will not be available locally until the client can reach an IPA server again. Plan shop floor access on the assumption that the cache serves known users, not every user in the realm.

Treat offline behavior as something to prove on each machine, not something to assume from the documentation. Behavior depends on the distribution, its SSSD version, the sssd.conf settings in use (including the cache and credential options your enrollment produced), whether the machine uses local or Kerberos-based authentication, and how PAM and the login stack are configured. Ask your integrator and your distribution vendor to confirm the offline login behavior for each exact combination you run, and record the result. Do not rely on a cache duration you have not measured on your own image.

Before go-live, test with the network to the replicas actually cut, not with a simulated timeout. Log in as several known users, including a user who has not logged in for a long time and one whose password was changed after the last connection. Confirm how sudo and access rules behave, since host-based access rules and sudo policy may depend on data the client has cached. Reboot the machine while disconnected and repeat the login. Finally, reconnect and confirm that the cache refreshes and that a password reset made during the outage is accepted. Keep the results with your change records, because these tests are the evidence that the shop floor will work when the plant network does not.

Which compliance obligations change the plant identity design

Several regulations touch plant networks, but only some change how FreeIPA is designed. The cards below separate the obligations that affect identity, logging and access from those that apply only to certain sectors. DeployOpen prepares systems, controls and evidence for assessments, but independent auditors and certification bodies issue the audit reports, attestations and certifications.

ISA/IEC 62443 zone and access design

The ISA/IEC 62443 series organizes requirements for industrial automation and control systems into general, policy, system and component groups. For FreeIPA, the asset owner's program requirements in ANSI/ISA-62443-2-1-2024 and the system requirements in ISA-62443-3-3-2013 shape which zones hold a local replica, which hosts enroll as IPA clients, and who can log in to each zone. Ask your security team to map zones and conduits before deciding where FreeIPA servers sit.

NIS2 reporting timelines

Manufacturing is a critical sector under NIS2 Annex II, covering the NACE Rev. 2 divisions for electronics, electrical equipment, machinery and transport equipment. In-scope entities must send an early warning within 24 hours, an incident notification within 72 hours and a final report within one month. Identity logs and a tested way to disable accounts on isolated hosts are what let you meet these clocks, so confirm which entity category your organization falls under.

CRA Article 14 reporting

The Cyber Resilience Act applies to products with digital elements from 11 December 2027, but manufacturers' Article 14 duties to report actively exploited vulnerabilities and severe incidents have applied since 11 September 2026. This matters if your plant builds or sells connected products, because FreeIPA patch levels and advisory tracking become part of your reporting chain. Fines under Article 64 reach EUR 15 million or 2.5% of worldwide annual turnover, whichever is higher.

Machinery essential requirement 1.1.9

The Machinery Regulation applies from 14 January 2027 and requires that connecting another device or a remote device does not lead to a hazardous situation. For machines with networked controllers, this means that remote and local logins must not be able to alter safety-relevant behavior without controls. Document which accounts can reach each machine, how SSSD behaves when the controller is offline, and how access is revoked.

CMMC only for defense work

CMMC under 32 CFR Part 170 applies to defense contractors. Level 1 covers the 15 FAR 52.204-21 safeguarding requirements, Level 2 covers the 110 NIST SP 800-171 Rev. 2 requirements for CUI, and Level 3 adds 24 selected NIST SP 800-172 requirements. Consider this card only if the plant handles federal contract information or CUI for defense work. Confirm the current phase status with your contracting officer, because the Department of War suspended CMMC Phase II requirements on 13 July 2026.

NERC CIP only in energy

NERC CIP-005-7 and CIP-013-2 apply to energy operators with BES Cyber Systems. If your plant is outside the electric sector, these standards do not govern your FreeIPA design, and you should not treat them as a checklist. If you are in energy, CIP-005-7 requires multi-factor authentication for Interactive Remote Access through an Intermediate System, and CIP-013-2 requires verification of software integrity for packages carried across isolated boundaries.

What manufacturers ask before hiring a FreeIPA partner

What drives the cost of an air-gapped FreeIPA build?

The cost follows the number of sites, servers, clients and integrations that must work without internet access, not the FreeIPA software itself, which is free under GPL-3.0-or-later. Cost components are the design work (topology, DNS, certificate authority and offline update path), the build and enrollment of servers and shop floor clients, testing of offline login, and documentation handed to the plant team. One-time work includes design, build and cutover. Recurring work includes patch intake, upgrades and support. Costs rise with each isolated zone, each OT system that needs SSSD offline login, and any integration with existing Active Directory or OT tooling. Ask any partner for a quote that lists these items separately, with the assumptions about sites and clients written down.

How long does an isolated FreeIPA deployment take to build?

Duration depends mainly on how many network zones and sites are in scope, how many shop floor systems must log in offline, how complete the existing network and asset documentation is, and how long change approvals take from the OT owner. Lab validation of replicas, certificate issuance and SSSD offline login on representative machines usually takes longer than the server installation itself. Plant shutdown windows and vendor sign-off on OT systems can set the critical path. Ask the partner for a written schedule with milestones for design approval, lab proof, pilot cell cutover and rollout, and confirm which of these depend on your staff or your vendors.

What must the plant team provide before a FreeIPA engagement starts?

The plant team needs to provide current network diagrams showing zones, conduits and firewall rules, an asset list of Linux and UNIX hosts with their roles, and the systems that must authenticate locally when the link to the corporate network is down. The OT owner must sign off on the design and on any change that touches a controlled zone. Other inputs include the existing LDAP or Active Directory sources, any vendor restrictions on installing agents or changing time and DNS settings, and a named contact for maintenance windows. Missing inputs usually become scope changes, so confirm the list with the partner before quoting.

Can an internal team run a FreeIPA build on isolated networks alone?

An internal team can run it alone if it already operates Linux identity services, understands Kerberos, DNS and certificate renewal, and has someone who can test changes against OT systems without disrupting production. The harder parts are usually the offline design decisions: replica placement per site, where the first server sits for certificate renewal and CRL publication, and how time and DNS resolve without the internet. The FreeIPA backup documentation warns that restoring an outdated backup into an active replica topology can break replication, so restore procedures need rehearsal. Decide which skills are missing, then choose between training, a fixed-scope build with knowledge transfer, or a retainer for operations.

How is software brought across the air gap and verified?

Packages, container images, FreeIPA updates and security content are prepared on a connected staging system, transferred on approved media, and checked before they reach the isolated network. Verification covers package signatures, checksums, an inventory of what was transferred, and a record of who approved it. For OT, NERC CIP-013-2 is a useful reference for the software integrity and authenticity controls that procurement should address, even outside the power sector. FreeIPA 4.13.4 fixed two CVEs, so a process to bring security releases across quickly is part of the design. Ask the partner to show the transfer procedure and the evidence it produces.

What does ongoing operation and upgrading involve for an isolated FreeIPA estate?

Operation includes monitoring replica health, renewing and tracking certificates, reviewing backups, testing restores, managing user and host lifecycle, and reviewing access rules. Upgrades move between 4.x releases in a planned order, with a test topology first, a rollback plan and a check that replication and certificate services stay healthy. Each upgrade on an isolated network also requires a new transfer cycle for the packages and a maintenance window agreed with the OT owner. These tasks recur for the life of the system. Ask for the cadence of checks, who performs each task, and how emergency security releases are handled.

Does FreeIPA keep shop floor logins working when the corporate network is down?

It can, when the shop floor clients are enrolled and SSSD is configured to cache credentials and allow offline login, and when a local FreeIPA replica is reachable from the cell. Whether a given system works offline depends on its PAM and login stack, its vendor support and how it handles Kerberos tickets, so each OT system needs a test on a representative machine. Confirm offline behavior in the lab before committing to a design, and record which systems cannot use it so they follow a separate local access procedure.

How DeployOpen scopes and delivers FreeIPA for isolated plant networks

DeployOpen plans, implements, hardens, documents and supports FreeIPA inside your own infrastructure, including segmented and air-gapped plant networks. Each engagement starts from a written scope that sets out which sites, replicas, certificates and shop floor systems are covered before any work begins.

How we scope

Map every plant zone, its network boundary and which systems must authenticate when the upstream link is down.
Agree in writing which FreeIPA replicas, CA functions, DNS locations and SSSD client builds are in scope.
Define how certificate material and software packages cross the isolation boundary, and who verifies them.

How we build

Design the replica layout per site, respecting the recommended replica counts and replication agreement limits.
Configure the internal certificate authority so issuance and renewal work without internet access.
Test SSSD offline login on representative shop floor systems, then document the cached credential behavior and its limits.

How we hand over

Deliver runbooks for backups, restores, certificate renewal and replica recovery, including the risk of restoring outdated backups.
Provide the test evidence from offline login, failover and replication checks, mapped to your plant's documented requirements.
Train your operations staff on routine tasks such as adding a client, rotating a key and updating an isolated mirror.

How we support

Support is available as a retainer covering patching, FreeIPA security releases and planned upgrades between 4.x versions.
Review each update for offline impact, including new certificate behavior and changes to DNS or authentication defaults.
Confirm the support boundaries, response expectations and change process with your team in the written agreement.