Why open source SSO for manufacturing starts with the plant floor
If you run IT or OT for a manufacturer, you already know the problem: the office directory holds the staff, but the MES, historian, maintenance system and engineering tools each keep their own logins, and some of them must keep working when a site loses its WAN link. Keycloak, authentik, ZITADEL or FreeIPA can centralize workforce login on infrastructure you control, but the right choice depends on your site topology and on which plant systems cannot speak SAML or OIDC at all. Those legacy systems usually decide the architecture before the product does.
The standards that shape this design are the ISA/IEC 62443 series, which organizes requirements for industrial automation and control systems into general, policy and procedure, system and component groups, and NIS2, which lists manufacturing as a critical sector in Annex II. Under ISA/IEC 62443, the plant network is normally its own zone with its own conduits to the office network, so the identity provider in the office is not automatically a trusted source for plant logins. Read the requirements in the ISA overview of the 62443 series with your OT security lead before you decide where each identity service runs.
Start with a short inventory: list every plant application and shared terminal, mark which ones support SAML, OIDC, LDAP or Kerberos, and note which must run with no connection to the office. Confirm with each vendor whether a local login fallback is supported and how it behaves during an outage. Those answers set how many identity nodes you place per site, whether FreeIPA's Kerberos model fits better than a web-first provider, and which applications stay on local accounts under a documented exception.
Which manufacturing requirements change the SSO build
This table maps each manufacturing requirement to what it means for MFA, session rules, local fallback, logging and supplier accounts in a self-hosted SSO build. Read each row as a design input: confirm which rules apply to your sites, subsidiaries and product lines before setting policy, since several apply only to specific entities.
| Requirement | What it asks for | What it means for the SSO build |
|---|---|---|
| ISA/IEC 62443 asset owner program (ANSI/ISA-62443-2-1-2024) | A documented security program for industrial automation and control systems, covering roles, access and incident handling at the asset owner level | Define which plant zones and roles the identity provider serves, document who approves access, and keep login policy in the same program as OT change control |
| System security requirements and security levels (ISA-62443-3-3-2013) | Technical requirements for system security, graded into security levels by zone and conduit | Set stronger authentication and session limits for higher-level zones, and ensure the identity provider sits in a zone that matches the level it serves |
| NIST SP 800-82 Rev. 3 on OT access and availability | Guidance that OT security must respect performance, reliability and safety, including access control on PLCs, SCADA and DCS | Design fallback so a line keeps running during an identity outage, and test that operators can still reach HMIs and historians with cached or local credentials |
| Shared terminals and shop floor logins | Unique user identification and controlled access on workstations used by several operators | Use fast user switching or badge-based sessions, avoid shared generic accounts, and set short idle timeouts that do not interrupt running processes |
| NIS2 Annex II manufacturing scope | Covers manufacturers in NACE Rev. 2 divisions 26 to 30 and medical or in vitro diagnostic devices as critical sectors, with MFA and access control measures under Article 21 | Plan MFA for remote and privileged access to office and plant systems, and keep identity logs that support incident handling |
| NIS2 incident reporting timelines (Article 23(4)) | Early warning within 24 hours, incident notification within 72 hours and a final report within one month for significant incidents | Keep authentication logs exportable and time-synced across sites so the team can reconstruct a compromised login within these windows |
| Machinery Regulation essential requirement 1.1.9 (Regulation (EU) 2023/1230, applies from 14 January 2027) | Machinery must be protected so connecting another or remote device does not lead to a hazardous situation | Treat remote vendor or engineer logins into machine controls as a safety-relevant path: require MFA, time-bound approvals and explicit session logging |
| Supplier and contractor accounts | Least-privilege access and accountability for third parties, which NIS2 supply chain and OT programs both expect | Use separate realms or groups with expiry dates, MFA for every external login, and recertification of supplier accounts on a set cadence |
| FTC Safeguards Rule and HIPAA (only where applicable) | FTC requires MFA and activity logging for covered financial institutions; HIPAA requires unique user identification and audit controls for ePHI | Apply these only to a financial subsidiary or a medical device line that handles customer or patient data, and scope those users into a separate policy set |
Which open source platforms fit a plant identity layer
A plant identity layer has to serve office directories, shop floor logins and supplier accounts, often with a weak WAN link between sites. The four platforms below cover different parts of that problem, so the choice depends on which protocols your legacy equipment speaks and where your identities already live.
Keycloak for broad federation
Keycloak is Apache-2.0 licensed and supports OpenID Connect, OAuth 2.0 and SAML 2.0, with LDAP and Active Directory user federation for plant and office directories. The Keycloak Operator is installed through Operator Lifecycle Manager and manages Keycloak and client resources on Kubernetes. Confirm that the Keycloak version you plan to run supports your chosen production database, and confirm that plant-floor clients such as HMI web front ends can use OIDC or SAML rather than requiring a separate proxy.
authentik for legacy equipment
authentik's core code is MIT licensed, with a separate enterprise license for the authentik/enterprise directory. Its provider types include LDAP, RADIUS, proxy and RAC, which can front older equipment that cannot run OIDC or SAML. Since the 2025.10 release it stores caching, tasks and sessions in PostgreSQL instead of Redis. Confirm which of your devices work with LDAP bind or RADIUS, and confirm that any feature you need, such as mTLS or privileged access, sits in the community edition.
ZITADEL for supplier tenants
ZITADEL is AGPL-3.0 licensed and lists SCIM and multi-tenancy in its README, which suits supplier and contractor accounts that need their own organizations inside one identity system. AGPL-3.0 carries network-use source disclosure duties when you modify the software, so have legal review the license before you customize it. Confirm how ZITADEL handles LDAP or RADIUS sources for plant equipment, since those are not the focus of its feature list.
FreeIPA for Linux estates
FreeIPA combines Kerberos and LDAP with certificate management, which fits plants that run Linux HMI servers, engineering workstations and file services. Kerberos tickets let domain-joined Linux hosts authenticate without a cloud dependency during a WAN outage. Confirm that your Windows and Linux machines can join the realm, that the Kerberos clock tolerance matches your site servers, and that web-based plant applications can accept Kerberos or a SAML bridge.
Protocol fit by platform
Before you pick a platform, list every system that must log in and record its protocol: OIDC, SAML, LDAP bind, Kerberos, RADIUS or none. Keycloak and authentik cover the widest range out of the box, ZITADEL leans toward modern web and API clients, and FreeIPA leans toward Kerberos and LDAP hosts. Systems with no supported protocol usually need a gateway or a proxy, which adds a component to test at each site.
Deployment patterns for sites that lose their WAN link
This pattern runs one primary identity provider cluster in a central data center or cloud region, with read-only directory replicas or cached directory data at each plant. Applications that are reachable over the local network can still authenticate users against the cached data when the WAN link is down, but anything that needs a live call to the central identity provider, such as a new login flow or a token refresh against a remote endpoint, will fail. The central design is simple to govern, yet it concentrates risk in one place.
- Local login during an outage: Only applications that are configured to accept locally cached credentials or tokens keep working. Confirm whether the plant applications use the central issuer URL for every token refresh.
- Database placement: Keycloak's supported high availability designs require a synchronously replicated database. Across plants connected by a WAN, that usually means the database stays in one site, so a WAN loss can take the whole cluster out of reach for remote sites.
- Directory replicas: Read-only copies of the user directory let plants resolve group membership locally, but password changes, account lockouts and deprovisioning only propagate after the link returns.
- Session and token lifetimes: Longer token lifetimes extend local access during an outage but widen the window for revoked accounts. Set them with your security team.
- Operator and upgrade windows: Patches to the central cluster are a maintenance event for every plant at once.
Before relying on this pattern, ask the vendor and your implementation partner which login flows are documented to work with the identity provider unreachable, and test each one with the link cut.
This pattern gives each plant its own identity provider for plant-only logins, such as operator dashboards, MES and historian web interfaces and local engineering tools. The plant instance brokers to the central identity provider for enterprise users, so staff from head office can still log in when the link is up. Plant logins keep working during a WAN outage because the identity provider and its database are local to the site, but each site becomes an independent identity system that must be operated, backed up and patched.
- Independent authentication: Accounts that exist only in the plant directory continue to authenticate during an outage without any call to the central site.
- Brokering limits: Federated logins from head office stop during the outage. Decide which roles are local and which must always come from the central directory.
- High availability per site: A two-node Keycloak cluster at a plant needs a synchronously replicated database, which typically means a second database host on the same local network. Many small plants will not justify that cost, so confirm whether a single-node design with tested backup and restore is acceptable for them.
- Account drift: Local copies of accounts can fall out of step with the central directory. A joiner, mover or leaver process must cover every plant instance.
- Patching by site: Each plant needs its own upgrade schedule and test evidence.
Confirm with the vendor how the chosen version handles brokering when the upstream provider is unreachable, and whether local sessions survive a restart of the plant instance.
This pattern places FreeIPA at the plant to handle Linux logins, host-based access control and Kerberos ticket issuance for shop-floor systems, while Keycloak or authentik handles web application single sign-on. FreeIPA serves as the local directory for Linux and Kerberos, so workstation and server logins do not depend on the WAN. Web applications can be run locally with the same local directory, or they can federate to a central identity provider when the link is up.
- Linux and Kerberos locally: Domain-joined Linux hosts and Kerberos-authenticated services keep working during an outage because the KDC is local to the plant.
- Split responsibilities: Two identity systems mean two sets of runbooks, backups and upgrade cycles. Assign an owner for each.
- Web SSO dependency: Keycloak or authentik at the plant needs its own database. The synchronous replication requirement for Keycloak high availability still applies to any multi-node design.
- Trust between realms: Define how the plant realm trusts the central directory, and which accounts the plant can create without central approval.
- Time synchronization: Kerberos is sensitive to clock drift, so plant time sources must be reliable when the WAN is down.
Ask your partner to document which applications authenticate locally during an outage, and test Kerberos ticket renewal and web logins together with the link cut.
How a manufacturing SSO rollout runs in phases
The sequence moves from inventorying applications and plant assets to a tested, documented cutover, so that workforce login works across office IT and the shop floor and keeps working when a site loses its WAN link.
Inventory applications and OT assets
DeployOpen works with your IT and plant engineering teams to list every application, shared terminal, HMI, MES and historian login path, and supplier or contractor entry point. For each system, the inventory records whether it supports SAML, OpenID Connect, LDAP, Kerberos or RADIUS, who owns it, and whether it can be changed at all. Systems that cannot take SSO are flagged for a compensating pattern. The inventory is complete when plant engineering and IT have both signed off on it.
Design zones and site topology
Using the inventory, the team draws a zone diagram that separates the corporate IT network, the plant network and any demilitarized zone, and shows where each identity provider node, directory replica and MFA component sits at each site. The diagram records which flows cross the WAN, which must stay local, and which network segments carry identity traffic. Reviewers check it against the ISA/IEC 62443 zone and conduit concept with your OT security owner. The output is an approved zone diagram with a flow matrix.
Run a pilot with office IT and one plant
The pilot connects a limited set of office applications and the systems at one plant to the identity provider in a non-production environment. Engineers test login, group mapping, session timeouts and failure handling against real plant workflows, with plant staff present for acceptance. Each defect is logged with an owner and a fix date agreed in writing. The pilot closes with a test report that lists passed, failed and deferred cases and the decisions taken on each.
Design shared terminal and kiosk login
Shared workstations, operator panels and kiosks need a login model that suits shift work: quick user switching, controlled session lock, and a clear rule for which accounts may share a device. The design sets how operators authenticate at the terminal, how sessions end at shift change, and what happens to local caches. Your security and operations leads approve the model and the settings are captured in a configuration export. The output is a documented design and a tested kiosk profile.
Define the supplier and contractor account model
Suppliers, integrators and contractors often need time-limited access to specific plant or vendor portals. The account model defines sponsorship, the groups they may join, expiry dates, and whether they authenticate through their own federated identity or a local account with MFA. Access reviews and removal steps are written into the runbook, with the owner of each external account named. The output is an approved account model and a sponsor responsibility matrix.
Roll out MFA and test WAN loss
MFA enrollment is staged by user group, with help desk scripts and fallback methods agreed before enrollment starts. In parallel, the team tests the WAN-loss scenario: what a site can still authenticate against when its link to the central identity provider is down, which cached or local credentials apply, and how the site recovers. Test cases cover login, MFA, application access and recovery after reconnect. The output is a WAN-loss test report with pass or fail results and the residual risks accepted by the business.
Cut over and hand over the evidence pack
Cutover follows a runbook with a rollback point, a go or no-go check at each site, and named decision makers. After cutover, DeployOpen assembles an evidence pack that contains the inventory, zone diagram, test reports, configuration exports, access model and operational runbook for your auditors and security team. Items the evidence pack cannot cover, such as the assessment itself, remain with your independent assessors. The step closes when operations accepts the runbook and the evidence pack is filed.
How shared shop-floor terminals and supplier access are handled
How do shared shop-floor terminals keep individual accountability without slowing shift handover?
Shared terminals keep accountability by requiring each person to sign in with a unique identity, then ending that session quickly when the shift changes, so the next person signs in as themselves. The design usually combines short session lifetimes, idle lock timers, and fast user switching that keeps the previous session locked rather than fully logged out, so the next operator does not wait for a full login. Every login, switch and logout should be written to a central audit log tied to the named user. Confirm with your MES, HMI and terminal vendors whether their applications accept an SSO session that can be switched without re-entering a password, because many industrial clients do not. Ask your implementation partner to test handover timing on the real terminals before rollout.
Do passkeys or badge login fit a manufacturing plant?
Both can fit, but they solve different parts of the problem and usually need a fallback. Passkeys built on FIDO2 and WebAuthn are phishing resistant and work well on office laptops and tablets that can hold a credential, and the ZITADEL and Keycloak documentation both list passkey support. Badge or smart card login suits shared terminals where people already carry a badge, but it depends on reader hardware, card formats and certificate issuance that must be planned with the plant's own vendors. Gloved hands, shared devices and kiosk-mode panels often rule out passkeys on the floor, so confirm device support for each terminal model before choosing. Keep a documented alternative method for staff whose badge is lost or damaged.
How do contractor accounts expire automatically?
Contractor accounts expire when the identity platform ties each account to an end date that comes from the contract or work order, and the account is disabled or removed at that date without a manual ticket. In a self-hosted setup this is usually handled by an identity governance tool or by lifecycle rules in the directory, fed by a sponsor who owns the contractor relationship. Check that the platform can set an expiry on the account itself, that the expiry also removes group memberships and active sessions, and that the event is logged. Ask the implementation partner to show a test where an expired contractor cannot sign in to any connected plant or office application.
How is supplier access limited to specific applications?
Supplier access is limited by giving each external user a separate account in a dedicated group, then assigning that group to only the applications they need, such as a specific portal, ticketing queue or machine documentation share. Keycloak and authentik both let administrators control which clients a user can reach through role or group assignments, and the access policy should deny by default. Keep supplier accounts apart from employee directories where practical, require MFA for every external login, and restrict network paths so the supplier cannot reach plant systems directly. Review supplier access on a schedule that matches your contracts and the supplier's own security obligations.
How are local break-glass accounts controlled and logged?
Break-glass accounts are a small set of local administrator credentials kept for use only when the central identity provider or its directory is unavailable. Store their passwords in a sealed, access-logged vault, rotate them after each use, and alert on every login. In practice, the account should be usable on the plant system itself, not only through SSO, and its use should be reviewed against a documented incident or change record. Test the procedure during planned downtime, because an untested break-glass account often fails when it is needed. Confirm with each plant system vendor how a local account can be created, disabled and audited, since not all industrial applications support this cleanly.
What do I need to confirm before supplier and contractor access can be scoped?
Before scoping supplier and contractor access, confirm the list of applications each external party needs, the sponsor who approves each account, the contract end dates, and the network paths they will use. Also confirm whether each application supports the protocols you plan to use, such as SAML or OIDC, and whether it can enforce per-application roles. These answers determine the number of groups, the expiry rules and the review schedule. Ask the implementation partner to produce a written access matrix that maps each external group to its applications before any accounts are created, so the scope is agreed in writing.
Evidence auditors and regulators ask for from an identity stack
This table maps the evidence a manufacturer typically needs to show for workforce SSO across office and plant systems to the component that produces it. Read each row as a question to ask: where the record comes from, which regulation or standard it supports, and who must confirm it. DeployOpen prepares systems and evidence for assessments, but independent auditors and certification bodies issue the findings.
| Evidence item | Produced by | What to confirm before an assessment |
|---|---|---|
| Exported MFA policy for office and plant logins | Keycloak authentication flows and realm configuration export; authentik flow and stage exports | Which applications and admin consoles are covered, and whether shop floor or remote vendor logins follow the same policy |
| Authentication and admin audit logs | Keycloak admin events and login events; authentik audit logging (enterprise editions carry enhanced audit logging) | Log retention period, forwarding to the SIEM, and whether plant-side login events reach the central store |
| Access review records for plant and contractor accounts | midPoint certification campaigns for identity governance, with review decisions stored as evidence | Who signs reviews, how often they run, and whether reviews cover supplier and contractor accounts |
| Session timeout and idle lock settings for shared terminals | Keycloak realm session settings; authentik session and flow configuration, plus endpoint policy | Whether shared kiosk sessions are short enough, and whether the endpoint enforces lock when the browser session stays open |
| WAN-loss test results for local authentication | Test records from the site (cached credentials, local directory or read-only replica), not from the identity provider itself | Which logins still work during an outage, how long cached access lasts, and who approves the test scenario |
| Change records for operator and identity stack upgrades | Keycloak Operator update approval records; version and migration logs; authentik upgrade notes and tested release versions | Whether updates use manual approval mode, whether schema migration was tested, and who authorized each change |
| Mapping to plant security frameworks | Control mapping prepared with the client against ISA/IEC 62443 requirements such as user authentication and access control | Target security level per zone and conduit, and which assessor will review the mapping |
What to ask an implementation partner about plant identity
Start with the topology, not the product. Ask the partner how they map OT zones and conduits before any design work begins, and who on the asset owner's side signs off that map. A useful partner will ask which plant networks can reach the identity provider, where the Keycloak or authentik nodes would sit relative to the DMZ, which historians, MES servers and HMI stations need directory-backed logins, and which of them are expected to stay under local control. Ask them to show how they document these decisions against the zone and conduit model in the ISA/IEC 62443 series, and how that documentation feeds the risk assessment described in ANSI/ISA-62443-3-2-2020. A partner who proposes a single central identity provider with no zone analysis has skipped the step that matters most on a plant floor.
Ask how they test login during a WAN outage, and insist the test is run, not described. Request a written procedure that disconnects a site from the head office network for a defined window and checks which logins still work, which fail, and whether cached sessions and local break-glass accounts behave as the plant expects. Ask whether the site will run a local identity node, how that node gets its user and group data, how it is kept in sync when the link returns, and what happens to password changes and MFA enrollments made during the outage. Ask how they handle the database under this design, because the Keycloak high availability documentation requires a synchronously replicated database for its supported designs, and a site-local node has to meet that requirement too. Also ask who on the partner team owns the test results and who on your side accepts them.
Ask how they handle legacy equipment that cannot speak SAML or OIDC. Many PLCs, older HMIs, instrument consoles and vendor-managed appliances authenticate with local accounts, LDAP binds or shared credentials, and they cannot be moved to a web login flow. Ask the partner to list every such device from your inventory, state which can be placed behind an authenticating gateway or jump host, which need an LDAP or Active Directory bridge, and which must stay on local accounts with compensating controls. Ask them to confirm which of these options Keycloak or authentik supports for each device class, and what they will not do, so the gap is recorded in the risk register rather than discovered in production. Finally, ask how upgrades are tested against plant applications. Request a staging environment that mirrors the plant's integrations, a written rollback plan, and confirmation that operator updates are applied under manual approval, as the Keycloak Operator documentation recommends, so a vendor patch cannot change login behavior on a production line without a change window.
How much does manufacturing SSO cost and what does it need from us?
What drives the cost of manufacturing SSO the most?
The biggest drivers are the number of plant and office applications that need single sign-on, the number of sites, and how many of those applications cannot speak SAML or OIDC natively. Each application that needs a connector, a proxy or a custom integration adds build and test work. Supplier and contractor accounts add scope because they bring their own onboarding, offboarding and MFA rules. Ask any partner to price the application list by protocol and site before agreeing a fixed scope, since that list determines most of the effort.
Can our in-house team run open source SSO for manufacturing?
Many teams can run the core identity provider, but the work splits into areas that need different skills. Running Keycloak, authentik or ZITADEL requires people who understand the identity platform, its database, backups, certificates and upgrades. Plant integrations also need people who know the control systems and change windows. Assess whether you have owners for identity operations, application integration and on-call support before deciding. A partner can plan, implement, document and hand over the work under a written scope, and ongoing support can be taken as a retainer.
How long does a manufacturing SSO rollout take?
Timelines depend on the written scope, not on a general rule. The main variables are how many plant applications are in the first phase, how many sites must be reached, whether a high availability design is required, and how much testing happens in production-like conditions before a plant cutover. Ask any partner for a phased plan that lists the applications, sites and acceptance tests in each phase, and tie the schedule to those deliverables.
What recurring costs should we budget for after go-live?
Recurring costs usually fall into four groups:
- Hosting for the identity servers in each environment you run, including test and disaster recovery copies
- A managed or self-run database, such as PostgreSQL, with backups and replication
- Upgrades and security patches, which the Keycloak project plans at four minor releases a year
- Support for incidents, application onboarding and access changes
Keycloak's high availability designs require a synchronously replicated database, which adds database cost. Confirm with any partner which of these items are included in the quote and which are billed separately.
Do we need paid authentik enterprise features or Red Hat build of Keycloak support?
Not always. The authentik Open Source edition is free, but the pricing page lists Google Workspace and Microsoft Entra ID integrations, mTLS client certificate authentication, privileged access management, password history and enhanced audit logging as enterprise-only. If your plant applications need those features, budget for the Enterprise edition, which the pricing page lists at $5 per user per month billed annually plus $0.02 per external user per month. Red Hat build of Keycloak is a supported distribution of the open source project, which may matter if you need a vendor support agreement. Confirm current pricing and terms with the vendors before deciding.
What does the shop floor team need to provide during the project?
The plant and IT teams need to provide an application inventory, network diagrams for each site, the WAN and firewall rules that separate plant and office networks, and named owners for each plant application. You also need change windows for cutovers, test accounts for each application, and sign-off on how shared terminal logins will be handled. Keycloak and authentik both use a database and a server layer, so your team should confirm where those components can run without depending on a single site's WAN link.
What should we ask a partner to put in the quote?
Ask for a written scope that lists each application, protocol, site and environment, plus the deliverables for each phase. The quote should separate one-time work, such as design, integration and testing, from recurring work, such as hosting, upgrades and support. Ask how upgrades are tested before production, how the identity provider is made highly available, what happens during a WAN outage, and what documentation and configuration exports you will receive at handover. DeployOpen does not publish a price list, so the quote follows from the written scope.
How DeployOpen scopes and builds plant identity
DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source identity platforms inside the client's own infrastructure, including plant networks where the identity provider must keep working through a WAN outage. Engagements are fixed-scope, with scope and deliverables agreed in writing before work starts.
How we scope
- Inventory every office, plant and shop-floor application and record whether it supports SAML, OIDC, LDAP or Kerberos.
- Define which sites must authenticate locally when the WAN link is down and which can depend on central services.
- Agree in writing which supplier, contractor and shared-terminal accounts are in scope and who approves their lifecycle.
How we build
- Deploy the chosen identity platform in the client's own environment, with the database and high availability design documented per site.
- Integrate directories, MFA and session rules for each application class, testing break-glass and offline behavior before cutover.
- Test platform upgrades in a staging environment before they reach production plant sites.
How we hand over
- Deliver architecture diagrams, configuration exports, runbooks for site outages and an application integration register.
- Document operator procedures for adding suppliers, rotating shared-terminal credentials and recovering locked accounts.
- Walk the client's administrators through the platform, so they can run day-to-day changes without DeployOpen.
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer after handover.
- Prepare configuration and access evidence that the client can supply to its own auditors or certification bodies.
- Confirm with the client the response expectations and service levels to write into the retainer, since DeployOpen does not publish them.
