Why authentik for manufacturing starts with the plant network
A manufacturer's identity problem is rarely one directory. The same engineers, integrators and equipment vendors appear in the corporate IT domain, in engineering tools, and in systems on the plant floor, and those systems sit in separate network zones that were designed to limit how traffic moves between them. authentik fits as a self-hosted identity layer that you run inside your own infrastructure, so one set of accounts, groups and MFA policies can drive sign-in to office applications, engineering servers and remote access gateways without sending authentication traffic to a public service. The open-source edition is MIT-licensed for most of the repository, while code in the authentik/enterprise/ directory is under a separate enterprise license, so confirm which features your plan requires before you design around them.
Once segmentation, offline sites and supplier access are in scope, the design changes. Each zone that needs to authenticate users must be reachable from an authentik component placed in that zone, which is where outposts and the choice of protocol (OIDC, SAML, LDAP or RADIUS) start to matter. Sites with restricted outbound access need a plan for container images, updates and any external sources before go-live, and supplier accounts need expiry, scoped groups and an offboarding path that does not depend on the supplier's own company. Confirm with your network and OT teams which flows the zone boundaries permit in each direction, because that answer determines where identity services can run. Those constraints, more than the login screen, set the scope and the effort of the project.
Which manufacturing requirements shape the authentik build
This table compares the manufacturing regulations and standards most likely to affect an authentik build, and what each one means for configuration, logging and vendor access. Read each row as an input to your design conversation, not as a statement of compliance, since authentik does not make a deployment compliant on its own.
| Requirement | What it asks for | What it means for the authentik build |
|---|---|---|
| ISA/IEC 62443 asset owner program (ANSI/ISA-62443-2-1-2024) | A documented security program for industrial automation and control systems, run by the asset owner | Define who administers authentik, which plant zones it serves, and how identity policy is documented and reviewed. Confirm with your OT security lead which zones and roles the program covers. |
| ISA/IEC 62443 risk assessment (ANSI/ISA-62443-3-2-2020) | Security risk assessment during system design, which drives zone and conduit decisions | Map which plant and engineering applications authentik signs into and which network paths carry those logins. The assessment should decide whether outposts sit inside a zone or at its boundary. |
| ISA/IEC 62443 system requirements (ISA-62443-3-3-2013) | System security requirements and target security levels for each zone | Set authentication strength, session timeouts and account lockout per zone. Confirm the target security level with your assessor before choosing MFA and session rules. |
| NIS2 Annex II manufacturing scope (Directive (EU) 2022/2555) | Manufacturing is a critical sector, covering NACE Rev. 2 divisions 26 to 30 and medical and in vitro diagnostic devices | Confirm with counsel whether your entity is in scope and whether it is essential or important. Scope drives how long you must keep authentication and admin logs available for review. |
| NIS2 reporting timelines (Article 23(4)) | Early warning within 24 hours, incident notification within 72 hours, final report within one month | Forward authentik audit and event logs to your SIEM so identity events, such as admin changes or repeated failed logins, can be reviewed inside those windows. Plan the log pipeline before go-live. |
| Cyber Resilience Act reporting (Article 71(2)) | Manufacturers' Article 14 duties to report actively exploited vulnerabilities and severe incidents have applied since 11 September 2026 | This applies to products you make, not to authentik itself. If you ship connected products, keep a named contact and a version inventory so you can respond. Track authentik security releases, which are announced at least 24 hours in advance. |
| Machinery Regulation essential requirement (Annex III, 1.1.9, Regulation (EU) 2023/1230) | Machinery must be protected so that connecting another or remote device does not create a hazardous situation, applying from 14 January 2027 | Remote access to machines through identity gateways should be tied to named, MFA-protected users with session logging. Confirm the requirement mapping with your machinery compliance lead and notified body. |
| Remote access comparison (NERC CIP-005-7, for reference) | Vendor remote sessions through an intermediate system with encryption, MFA and the ability to disable active sessions | Not a manufacturing mandate, but a useful benchmark. Ask whether your vendor access design can disable live sessions quickly and log who connected, and whether authentik's session controls cover that need for your protocols. |
How authentik placement changes by network zone
In corporate IT, authentik can run alongside your other identity and hosting services. The server container, which includes the core application and an embedded outpost, and the worker container, which runs background tasks, can sit on the same hosts or cluster. PostgreSQL stores all configuration and data except uploaded files, so it is the component to size, secure and back up first. The Docker Compose guide positions Compose for test setups and small-scale production, with at least 2 CPU cores and 2 GB of RAM as the documented host baseline. Larger estates usually move to Kubernetes with Helm.
- Server and worker: run both containers from the same release so background tasks match the web application.
- PostgreSQL: use a separately managed instance for production, since the Helm chart's bundled database is intended for demonstration and test environments.
- Inbound access: users and applications reach authentik through its public URL, and everything else can stay closed.
- Outbound access: confirm which connections your chosen sources need, such as Google Workspace or Entra ID integrations, which are Enterprise features.
Before opening any outbound rule, list the destinations your configured sources and flows actually use.
The plant DMZ is the usual home for authentik when plant users and corporate users both need to sign in, but the plant network must not depend on corporate systems to operate. Place the server and worker containers in the DMZ, with a reverse proxy as the only inbound path from plant and corporate networks. PostgreSQL should sit in the same zone or in a tier that only the authentik containers can reach. Plant zones should never reach the database directly, because it holds every configured credential source, application and policy.
- Server and worker placement: keep both containers in the DMZ and restrict their network reach to the directories and applications they must serve.
- Database isolation: allow connections to PostgreSQL only from the authentik containers, and block plant zones from the database port.
- Outbound allowlist: permit only the update and registry sources you have approved, plus any upstream directories.
- Proxy outposts: place an outpost close to applications that cannot speak OIDC or SAML, under the same firewall rules as the rest of the DMZ.
Ask your security team to confirm which DMZ rules block traffic from plant networks to PostgreSQL and to the management interfaces of the containers.
OT-adjacent zones hold engineering workstations, historians and manufacturing execution systems that sit close to control networks. authentik should not run inside a control segment. The ISA/IEC 62443 series organizes industrial security around zones and conduits, and ANSI/ISA-62443-3-2-2020 covers the risk assessment used to define them. The identity path should cross a defined conduit into the zone, with authentik kept in a zone whose compromise does not reach control systems. Authentication for engineering tools usually reaches authentik through a DMZ or outpost placed at the boundary, not from the control network itself.
- Engineering workstations: authenticate from a zone that can reach authentik through a defined conduit, rather than from the control network.
- LDAP and RADIUS clients: confirm which devices need direct protocol access and document each allowed flow.
- Availability: confirm that a loss of the identity path does not stop line operation, and plan local access for safety-relevant functions.
- Machinery requirements: Regulation (EU) 2023/1230 applies from 14 January 2027 and requires that connecting another or remote device does not lead to a hazardous situation, so remote access paths need engineering review.
Confirm with your OT security lead exactly which zone boundary the identity path crosses and what the zone risk assessment permits.
A plant with no outbound access still needs authentication, so authentik must be served entirely from inside the site. The server, worker and PostgreSQL run on local infrastructure, and every container image, package and update must reach the site through an internal registry or approved transfer media. The Kubernetes guidance for isolated clusters follows the same pattern: images are fetched in advance and pointed at a private registry. The architecture documentation describes the components to mirror and back up. Confirm the air-gapped installation and update steps for your release with authentik before the site is isolated.
- Image mirroring: pull every image for the release you deploy into an internal registry before the site loses connectivity.
- Update transfer: move release bundles on controlled media and verify checksums and provenance before import.
- Local data: keep PostgreSQL and backup storage inside the site, and test restores without any external service.
- Local directories: point users at the plant's own directory, since cloud-only sources cannot be reached.
- Licensing: check which features you need are in the open-source edition, because the pricing page lists several as Enterprise-only.
Ask for the offline install and update procedure in writing, and test a restore on an isolated network before go-live.
Which authentik providers and settings matter on the plant floor
A manufacturing site rarely runs one login path. Engineering web apps, legacy plant software, network access and remote vendor sessions each need a different authentik provider, and each provider carries its own configuration and risk. The cards below set out which provider fits which system and which features depend on the Enterprise edition.
OIDC and SAML for engineering and MES apps
Modern engineering, document control and manufacturing execution system (MES) web applications usually support OAuth2/OIDC or SAML, so they are the simplest integrations. Create one provider per application, set redirect URIs and signing settings exactly as the application expects, and confirm which group claims the application reads for role mapping. Test a plant-floor user who is not in the engineering group to confirm access is denied. Ask each application vendor which protocol and attribute format it supports before you start.
LDAP for legacy plant applications
Older historian, SCADA-adjacent and engineering tools often authenticate only against an LDAP directory. authentik's LDAP provider lets these applications bind without changes to their code, but the bind account, base DN and group filters must be scoped tightly, because legacy clients often expect plain binds. Confirm whether each application requires LDAPS or StartTLS and whether it can handle multi-factor prompts, which it usually cannot. Plan an exception register for these systems so they are reviewed at each access review.
RADIUS for VPN and Wi-Fi access
Remote access gateways, firewalls and plant Wi-Fi controllers commonly authenticate through RADIUS. authentik provides a RADIUS provider type, so network teams can keep their existing gateways and move identity decisions to authentik. Check how the network device sends the password or one-time code, the shared secret handling, and whether the device supports the second factor you plan to enforce. Test a failed login and a lockout before the change window, since a misconfigured RADIUS path can cut off operators who need to reach the plant.
Proxy provider for apps without SSO
Some plant dashboards, maintenance pages and internal tools have no SSO support at all. The proxy provider places authentik in front of them through an outpost, so access is decided before the request reaches the application. Confirm which reverse proxy you run, where the outpost sits relative to the plant network segment, and whether the application relies on its own login for user identity in logs. Treat the proxy as a control point and monitor its health, because an outage blocks access to every protected page.
RAC for remote engineering access
Vendors and internal engineers often need to reach an HMI, engineering workstation or remote desktop without a general network path. authentik's remote access control (RAC) provider brokers that session so the user signs in through authentik and reaches only the connection assigned to them. Decide which sessions require approval, how recordings are stored, and how an active vendor session is ended. These questions matter most for control-system access, where a supplier session can change process settings.
SCIM for downstream provisioning and audit
SCIM lets authentik create, update and deactivate accounts in downstream applications, so plant and supplier access can end when a contract or shift role ends. Map which attributes each application accepts, decide who approves a new supplier account, and confirm how deprovisioning is tested. Enhanced audit logging and privileged access management are Enterprise-only features on the authentik pricing page, so check whether your audit evidence needs them before you design the logging path.
How a manufacturing authentik rollout runs in phases
The sequence moves from knowing what sits on the plant network to a tested pilot, then to cutover and supplier access, with evidence captured at each gate. Each phase ends with a named sign-off so that operations, security and the plant owner agree before the next step begins.
Inventory zones, assets and identity sources
The team lists every plant, engineering and supplier-facing system that needs a login, the network zone each one sits in, and the directories or local accounts that hold its users today. DeployOpen typically runs this with your OT engineers and your identity owners, using a site walk-through and existing network diagrams as inputs. The phase is complete when the inventory is signed off by the plant owner and the identity owner, and every system has a named protocol candidate such as OIDC, SAML, LDAP, RADIUS or proxy.
Run the risk assessment against ISA/IEC 62443
Using the zone and conduit view from the inventory, the team assesses risk for each zone and sets the target security level for the authentication path into it. The work follows the ISA/IEC 62443 series, in particular the asset owner program requirements in ANSI/ISA-62443-2-1-2024 and the system design risk assessment in ANSI/ISA-62443-3-2-2020. The output is a signed risk register that states which zones authentik will serve, which must stay on local accounts, and which compensating controls apply. Security and the plant owner sign the register before any design work starts.
Pilot authentik with one plant
The team deploys authentik and connects a small set of low-risk applications at one site, such as an engineering document portal or a historian web front end, with a documented rollback path. Operations staff test login, MFA enrollment, lockout recovery and what happens when the upstream directory is slow. The pilot closes when the test script has passed on production-like hardware, the rollback has been exercised, and the plant operations lead accepts the results in writing.
Design outposts and offline behavior
Using the pilot results, the team decides where outposts run for each segmented zone, how they reach the core over approved conduits, and what happens to logins when the link to the core is lost. Decisions cover outpost placement, certificate handling, time synchronization and whether any zone needs local fallback accounts under a documented procedure. The output is an architecture diagram and a failure-mode table, reviewed by network engineering and the zone owners.
Cut over VPN and firewall authentication
The team moves VPN concentrators, firewall administrator logins and remote engineering access to authentik in agreed change windows, one zone at a time. Each cutover keeps the previous method available until the new path has been used by the pilot group and the rollback has been confirmed. The phase produces a change record per zone, the MFA configuration for each entry point, and a list of retired shared accounts. Network security signs off each zone before the next one moves.
Onboard supplier and vendor access
External integrators and equipment suppliers receive separate accounts with limited applications, time-bound access and a named internal sponsor for each identity. The team checks how each supplier session is started, recorded and removed, and confirms that remote sessions into controlled zones can be detected and ended. Output is a supplier access register with sponsors, approved applications and removal dates, signed by procurement and the plant security owner.
Capture audit evidence and hand over
The team collects configuration exports, change records, test results, access reviews and log samples into one evidence folder mapped to the risk register. Operations receives runbooks for backups, upgrades and recovery, and the team confirms which evidence the compliance owner needs for NIS2, the Cyber Resilience Act or customer audits. DeployOpen prepares this evidence but does not issue audit reports, so the handover states which items the independent auditor must review. Closure requires sign-off from the CISO or delegate and the plant owner.
What manufacturers ask before hiring a partner for authentik
What drives the cost of an authentik implementation for a plant?
Cost is driven by how many systems need sign-on, how many protocols they use, and how much of the work sits in your own network. The main components are discovery and design, the build of the authentik server and PostgreSQL, the provider and application configuration for each plant or engineering system, testing, and handover. Infrastructure is usually a one-time build plus recurring hosting and staff time. Ask any partner for a written scope that lists each application, its protocol (OAuth2/OIDC, SAML, LDAP, RADIUS or proxy), the sites involved, and who pays for hosting, licensing and ongoing upgrades. Expect the quote to separate one-time work from recurring support.
What does authentik Enterprise cost on the pricing page?
The authentik pricing page lists three editions: Open Source at no charge with community Discord support only, Enterprise at $5 per user per month billed annually plus $0.02 per external user per month, and Enterprise Plus starting at $20k annually. Enterprise adds features such as Google Workspace and Microsoft Entra ID integrations, mTLS client certificate authentication, privileged access management, password history, enhanced audit logging and ticket-based support for subscriptions over $1k. Enterprise Plus adds dedicated support with SLAs, multi-instance deployment support and FIPS compliance for FedRAMP requirements. Confirm current figures on the authentik pricing page before budgeting, because vendor terms can change.
How long does an authentik manufacturing rollout take?
No duration is fixed in advance, because timing depends on the number of applications, the protocols each one needs, and how many sites and network zones are involved. Work usually moves through discovery of plant systems, a design that places the server and any outposts, a pilot with one application, and then staged rollout. Engineering systems that depend on vendor support windows or change control often set the pace more than the authentik work does. Ask for a timeline in the written scope with milestones tied to each system, and confirm which change approvals your site needs before work begins.
What does the plant team need to provide for an authentik project?
The plant and IT teams need to supply an accurate inventory of systems that will sign users in, the protocol each one supports, and the user groups that should reach it. They also need network diagrams showing segments, firewalls and any site-to-site links, plus the names of owners who can approve access changes. Access to a test environment, a change calendar for production windows, and a documented process for emergency local login are also needed. Request a list of these inputs in the scope document so gaps are found before the build starts.
Can our internal IT staff run an authentik deployment without a partner?
Internal staff can run authentik if they have experience with Linux hosts, containers or Kubernetes, PostgreSQL, reverse proxies and directory protocols such as LDAP. The authentik Docker Compose guide positions Compose for test setups and small-scale production, while the Kubernetes guide recommends a separately managed PostgreSQL for production. Operations work includes upgrades, backups, monitoring and handling lockouts, which recur every year. Plants often assign this to a small team, so consider whether that team can cover on-call and upgrade windows. A partner can cover the build, handover and documentation, and the decision depends on your team's capacity.
What does an offline or segmented plant network need from authentik?
An offline or segmented network needs every container image, package and update to be staged inside the boundary before deployment. It also needs an internal PostgreSQL, time synchronization, internal certificate management and a process for moving signed update media across the boundary. Outposts placed in each segment let protected services keep working when the central server is unreachable from the plant floor, but you must confirm which features and outpost types behave this way in your version. Ask your vendor to confirm supported air-gapped installation steps, and check whether your site needs the Enterprise features for certificate-based login before committing to a design.
Which compliance requirements affect authentik access design in manufacturing?
Manufacturers often map access controls to ISA/IEC 62443, which sets security requirements for industrial automation and control systems, and to NIS2 if they fall into its manufacturing scope. ANSI/ISA-62443-3-3-2013 covers system security requirements and security levels, which shape how plant access should be authenticated and logged. NIS2 requires significant incidents to be reported within set deadlines, so logs from authentik must reach your incident process. DeployOpen prepares systems, controls and evidence for compliance assessments but does not issue audit reports or certifications. Confirm with your assessor which controls apply to your sites.
What should a manufacturer check before accepting an authentik build?
Check that the agreed scope lists each application, protocol, site and outpost, and that acceptance tests cover login, MFA where supported, group-based access, logout and recovery at each site. Verify that backups of PostgreSQL restore successfully in a test environment, that logs are forwarded to your monitoring system, and that the upgrade path is documented. Confirm the authentik version in use and check the authentik security policy for supported release lines, since the project announces security releases at least 24 hours in advance. Require a written handover covering runbooks and owners.
Audit evidence manufacturers should plan for
Manufacturers preparing for an assessment need evidence that shows who could reach plant and engineering systems, how those accounts changed, and how software entering isolated zones was checked. The cards below cover the records authentik and the surrounding process can produce, and the gaps your team should close before an auditor asks.
Access logs and enhanced audit logging
Authentication events, application sign-ins and administrative changes in authentik are the core record of who reached a plant or engineering application and when. Enhanced audit logging is listed as an Enterprise-only feature, so confirm whether your edition includes it before you design the evidence process around it. Decide where logs are forwarded, how long they are kept, and who can alter or delete them. Test that a sample sign-in can be traced from the identity event to the downstream application log.
Supplier account lifecycle records
Supplier and contractor accounts for engineering vendors are often the weakest part of the access record. Keep a dated trail for each account covering the approving owner, the applications granted, the MFA method enrolled, periodic reviews and the removal date. Plan for expiry so that a vendor account that is not renewed stops working without a manual step. Auditors will ask for this trail per supplier, so design it per supplier from the start.
Change records for upgrades and security releases
Every authentik upgrade and security patch changes the system that controls access, so each change needs a record of the version before and after, the test results and the approval. The security policy lists 2026.5.x and 2026.8.x as the supported lines receiving security fixes, and security releases are announced at least 24 hours in advance. Use that window to schedule the change, not to skip the review. Keep the release notes and rollback plan with the ticket.
Software integrity checks for isolated zones
Container images, binaries and updates carried into segmented or offline plant networks need a verification record. Keep the checksums or signatures you verified, the source you downloaded from, the person who approved the transfer and the date it entered the zone. NERC CIP-013-2 is an example of a framework that asks for verification of software integrity and authenticity for vendor software and patches, and similar expectations appear in other programs. Confirm the exact verification method with the vendor and your own procedure.
Evidence readiness for auditors
Auditors assess whether controls operate, so the evidence has to be organized by control rather than by tool. Map each access control to the record that proves it, name the owner of each record, and run a sample walkthrough before the assessment. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications. Independent auditors and certification bodies make those determinations.
What to ask a partner before committing to a plan
The first question to ask is how the partner handles offline updates and package verification for a segmented network. Ask who builds the bundle of container images, Helm charts and PostgreSQL packages that crosses the boundary, how each artifact is checked for integrity and authenticity before it is imported, and where the record of that check is kept. Under NERC CIP-013-2 this is a supply chain procurement control, and manufacturers facing NIS2 or the Machinery Regulation will expect the same evidence. Ask for the written transfer procedure, the rollback path if an update fails inside the isolated zone, and the names of the people who approve each transfer. Confirm which parts of the authentik deployment need internet access at install time and which do not, because a partner who cannot answer that plainly has not tested the offline path.
The second group of questions covers OT and IT boundary documentation. Ask the partner to show the zone and conduit diagram they will produce, which identifies every flow that crosses from the plant network into the identity services, and which of those flows are LDAP, RADIUS, SAML or OIDC. Ask who owns the firewall rules on each side and whether the design follows the zone and conduit model in the ISA/IEC 62443 series, which the partner should be able to explain in their own words. Then ask who owns outposts and PostgreSQL after handover. A plan should name the team that patches outposts, the team that runs the database backups, and the person who signs off a PostgreSQL major version change. If the answer is "we will train your team" without a named owner, the plan is not finished.
Finally, ask how upgrades follow the sequential rule. Request the upgrade path the partner will use from your current authentik version to the target, the release notes they reviewed for each step, and the test environment where each step runs first. Check the supported versions in the authentik security policy at the time of signing, and ask how the partner will receive the 24-hour advance notice for security releases when your network is offline. Ask for the scope in writing before any work starts, including deliverables, acceptance tests and what is excluded. Most DeployOpen engagements are fixed-scope, so an agreed written scope is what defines the work, the cost and the handover.
How DeployOpen works on this
DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure, including the plant, engineering and segmented networks described on this page. Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
How we scope
- Map which plant, engineering and supplier applications need sign-on, and which networks, zones or offline sites the authentik deployment must reach
- Record the provider types, outposts and MFA methods planned for each system, including any LDAP or RADIUS clients that cannot use modern login flows
- Agree the written scope, deliverables and timeline, with any edition or licensing questions confirmed against the authentik pricing page before work starts
How we build
- Deploy authentik in your own accounts, data centers or segmented networks, with PostgreSQL, storage and reverse proxy choices documented for your environment
- Configure providers, outposts and access policies for each application, then test login, MFA, failover and offline behavior against a staging copy
- Verify the software artifacts carried into isolated zones, recording checksums and version pins so the supply chain steps are repeatable
How we hand over
- Deliver configuration documentation, runbooks for lockouts, outpost restarts and upgrades, and a record of the access decisions made for each system
- Provide evidence packs of access control settings, audit log configuration and test results that your own auditors or compliance team can review
- Walk your operations and engineering staff through day-two tasks so your team can run the platform after handover
How we support
- Offer ongoing support, upgrades and testing as a retainer, with upgrade planning that follows authentik's sequential upgrade rule and release notes
- Plan periodic reviews of security releases, supported versions and changes to the authentik security policy against your change control process
- Coordinate updates to outposts and PostgreSQL in segmented sites, with rollback steps agreed before each change window
