Why an open source intranet for manufacturing starts with frontline access
On a plant floor or in a field operation, most people who need the intranet have no corporate mailbox and few have a desk. For this audience, the intranet must be reachable from shared kiosks and personal phones, and identity must work for workers who are not in the corporate directory. Those two requirements should be settled before anyone compares features. Between HumHub, XWiki and Nextcloud, the decision depends mostly on three things: how well the platform works on mobile browsers and shared devices, which identity models it supports for accounts created outside Active Directory, and who is allowed to publish content, from central communications down to shift leads and safety coordinators.
Expect the answer on mobile access and identity to narrow the field. Check whether each candidate's mobile experience covers reading news, acknowledging safety notices and submitting simple forms on a small screen, and whether a kiosk session can be locked to one user and reset at shift change. On identity, confirm which login options the edition you need supports, whether accounts can be created and disabled centrally for contractors and seasonal staff, and whether a worker can sign in with a shared badge or PIN process that your security team has approved. Ask the vendor or partner to demonstrate these flows on a test instance, not in a slide deck.
The industrial regulatory context shapes hosting and network placement more than the intranet features do. Operational technology work follows the ISA/IEC 62443 series, and NIS2 lists manufacturing as a critical sector, which brings reporting obligations for in-scope entities. The Machinery Regulation adds an essential requirement that connected devices must not create hazardous situations. In practice, this usually means the intranet sits in the corporate IT zone, not on the production network, with controlled paths to plant systems. Confirm with your OT and compliance leads which zone and conduit model applies before you choose a hosting location, because that decision determines how kiosks and plant-level spaces can reach the platform.
Which requirements shape the intranet build in manufacturing
This table maps each regulatory or standards source that touches a manufacturing site to what it means for an intranet that plant and field staff reach from shared kiosks and phones. Read each row as a design constraint: the requirement is the source, the build effect is what the intranet team should do, and the evidence column names what an assessor or auditor would ask to see. Treat the table as a starting point for scoping, since applicability depends on your sector classification, product line and entity status.
| Requirement source | What it asks for | Effect on the intranet build |
|---|---|---|
| NIS2 Annex II (manufacturing scope) | Lists manufacturing as a critical sector across NACE Rev. 2 divisions 26 to 30, with significant incident reporting under Article 23 | Confirm whether your entity is in scope. If so, the intranet becomes an asset in the incident register and must appear in incident response runbooks with named owners |
| NIS2 Article 23 reporting timelines | Early warning within 24 hours, incident notification within 72 hours, final report within one month | Build an intranet alert path that does not depend on the intranet itself, since it may be the system that is down during an incident |
| ISA/IEC 62443 zones and conduits | Separates industrial control zones from business zones and controls the conduits between them | Keep the intranet in a business zone with no direct route into OT networks, and document every firewall rule that links the two |
| NIST SP 800-82 Rev. 3 (OT boundaries) | Guides securing operational technology, including PLCs, SCADA and building access systems, with safety and reliability in focus | Do not host intranet components on OT segments, and do not use intranet notices or plugins to send machine commands or alerts |
| Machinery Regulation (EU) 2023/1230, Annex III 1.1.9 | Applies from 14 January 2027 and requires machinery to be protected so a connected device or remote device cannot create a hazardous situation | Exclude machine control messaging from the intranet, and restrict any shop-floor kiosk to read-only content with no write path to machines |
| Cyber Resilience Act, Regulation (EU) 2024/2847 | Manufacturer reporting duties for actively exploited vulnerabilities and severe incidents apply from 11 September 2026 under Article 71(2) | If your products include digital elements, keep vulnerability and incident records in a system the intranet can link to, but do not publish product security details on broad spaces |
| Access and audit logging for shared devices | Expected in most assessment frameworks that cover shared accounts and kiosk use, such as audit controls for systems holding sensitive records | Use named identities or short-lived kiosk sessions, log logins and sensitive page views, and retain logs in a store the plant cannot edit |
How frontline workers reach the intranet: kiosks, phones and personal accounts
Kiosks are shared browser terminals placed in break rooms, gates or along production lines. Several people use the same device across shifts, so the design has to assume that the next user is not the previous one. The safest pattern is a locked-down browser session that starts from a fixed intranet address, requires a fresh sign-in for each worker, and ends automatically when the worker leaves. Content should be limited to shift news, safety notices and plant-level spaces that a shared screen can show without exposing personal or production data.
- Authentication: Use a short personal login, such as a badge tap that maps to a directory account or a PIN tied to an identity record, and confirm with the platform vendor which login methods work in its kiosk or single-browser mode.
- Session length: Set a short idle timeout and a hard maximum session, then clear cookies and local storage when the session ends.
- Content shown: Limit the home page to shift news, safety notices and plant spaces, and keep personal profiles and direct messages off shared screens.
- Device hardening: Lock the browser to the intranet domain, disable downloads and printing where policy requires, and review the kiosk's operating system patch level on a set schedule.
- Network placement: Serve kiosks from the corporate IT zone, not from the OT network, and allow only the ports the intranet needs.
Confirm with your integrator how the chosen platform handles session expiry on kiosk browsers before you finalize the timeout values.
Many frontline workers have no corporate email address but do have a personal phone. For them, the intranet is usually reached through a browser or a mobile app on a device the company does not manage. Access should rely on an invitation or a registration code, a verified phone number or a personal login, and a narrow set of content that does not include confidential engineering or customer data. Sessions on personal devices should be shorter than on managed devices, and the company should plan for workers leaving the site, since their access has to end without relying on a corporate mailbox.
- Enrollment: Issue invitations through a supervisor or HR process, and confirm which self-registration or invitation options the platform offers before you commit to a workflow.
- Authentication: Decide between local accounts with multi-factor authentication and federated sign-in, and confirm which factors are supported on mobile browsers.
- Session length: Use shorter sessions for unmanaged devices, with re-authentication after inactivity, and confirm how the mobile app stores tokens.
- Content shown: Restrict personal phones to shift news, safety notices and onboarding material, and keep sensitive procedures in spaces that require managed devices.
- Offboarding: Tie account deactivation to HR exit events so access ends on the last working day, not when someone remembers.
Ask the platform vendor which mobile apps are maintained, how push notifications are delivered, and whether the app works behind the plant's network restrictions.
Office staff use managed workstations with corporate identity, so they can use the full intranet with standard single sign-on, longer sessions and access to spaces tied to their roles. This group usually also manages the content that frontline workers see, which makes workstation access the control point for publishing. The design question is less about authentication and more about how office users push plant content to the right kiosk and phone audiences without granting plant managers broader rights than they need.
- Authentication: Use single sign-on with the corporate directory and enforce multi-factor authentication for administrators and content publishers. Confirm which SSO protocols the platform edition supports.
- Session length: Apply standard corporate timeouts, with stricter limits for administrative sessions.
- Content shown: Give office users access to all spaces their roles require, including management and policy spaces that frontline audiences should not see.
- Publishing rights: Separate the ability to write plant news from the ability to administer spaces and users, and log every change.
- Audience targeting: Confirm whether the platform can target notices by site, shift or group, so a plant notice does not reach unrelated audiences.
Check with the vendor which audience and visibility settings are available in the edition you plan to use, because targeting features often differ between editions.
Which open source intranet platform fits a plant or field workforce
Plant and field staff need different things from an intranet: short shift news, written procedures they can find on a shared device, and files that a line supervisor can open. HumHub, XWiki and Nextcloud each cover one of these needs well, and each has its own license, edition and directory limits to confirm before you commit.
HumHub for shift news and spaces
HumHub organizes communication into spaces, which map well to plants, shifts or departments, and it suits the news and posting pattern that replaces email blasts for workers without a corporate mailbox. Before you design around it, confirm the license of the edition you plan to run, whether mobile posting works well for your workers' devices, and which directory options (LDAP or SAML) require the Professional Edition. Test the notification path for workers who never log in from a desk.
XWiki for procedures and rights
XWiki is licensed under LGPL 2.1, and its fine-grained rights suit controlled documents such as lockout procedures, machine guards and permit steps, where each plant needs to see only its own content. Directory integration is where the edition matters: XWiki Pro lists Active Directory and Azure Active Directory SSO applications, while the free Standard edition does not. Confirm the user tier you need, since Basic covers up to 1,000 users.
Nextcloud for shared plant folders
Nextcloud fits file-centered work such as shift handover sheets, inspection photos and drawings that a supervisor shares with a team. Nextcloud Server is licensed under AGPL-3.0, so review the obligations with your legal team if you modify it. Check how shared folders are scoped to groups, how external guest links are controlled, and whether your field devices can reach the server over the network paths your plants allow.
Accounts for workers outside the directory
None of the three platforms solves the identity question on its own. Many plant workers have no entry in the corporate directory, so decide whether they receive local accounts, an invitation flow managed by HR or a plant administrator, or access through a shared kiosk identity. Each option changes who approves access, how leavers are removed and what evidence an auditor can see. Confirm the exact account types each platform supports before you write the access model.
Shared kiosks and mobile sessions
Plant terminals and shared tablets change the risk profile of an intranet, because one person's session can expose another person's safety notice or procedure. Test how each platform handles session timeouts, sign-out on shared devices and access from personal phones used during a shift. Confirm whether mobile use depends on a browser, a native app or a particular edition, and set a rule for which content may appear on a kiosk.
Where the intranet sits relative to plant networks and corporate IT
A plant intranet touches more networks than a corporate one, so placement decisions come before product choice. The components below each have an integration point, a hosting choice and a question for the network team to settle before any server is built.
Intranet application tier
The web and application servers serve the same pages to office staff and to kiosks and phones on the plant floor. Decide whether they run in the corporate data center, in a plant-adjacent rack, or in cloud accounts, and whether plant users reach them through a DMZ or only over a routed path. Confirm with the network team which zones may open HTTPS to this tier and whether it must keep working when the link to head office drops.
Database tier
The database holds posts, spaces, file metadata and audit entries, so it should never sit in a zone that plant devices can reach directly. Keep it in the corporate data center or a restricted server segment, reachable only from the application tier. Ask the network team whether replication to a second site is allowed and which ports the firewall will permit between the two tiers.
Identity source
Many plant workers have no entry in the corporate directory, so the identity source is a design choice rather than a given. Options include the corporate directory for salaried staff, a separate plant-level account store for shift workers, and kiosk accounts with limited scope. Confirm with identity and HR teams how contractors and temporary workers are provisioned and removed, since account lifecycle is where most exposure builds up.
Reverse proxy and network segmentation
A reverse proxy in a DMZ is the usual entry point for mobile and remote access, while plant networks stay segmented from the business network. Place the proxy so that traffic from the plant reaches the intranet without routing plant devices into corporate IT. Confirm with the network and OT teams which zone the proxy sits in, how TLS is terminated, and who owns firewall change requests for it.
Backup and restore path
Backups must reach a location that a plant-side failure or ransomware event cannot reach through the same credentials. Decide where the backup target sits, how often data is copied off the plant, and how a restore is tested. Confirm with the infrastructure team the retention period for news and audit records, and whether a restore can be rehearsed on an isolated network without touching production.
Running safety notices and shift news without creating a second incident channel
Safety notices on a manufacturing intranet are a communication tool, not a record of what happened on the floor. Treat them as a separate content type from shift news: a safety notice needs mandatory acknowledgement by each named audience, a plant-level space with a named owner, and a supervisor who can edit or withdraw the post. Shift news and toolbox-talk summaries can stay informal, but they should carry the plant, line and shift in the space name so that a worker on the night shift does not read a day-shift notice as current. Decide before launch which content types need acknowledgement tracking, and configure the intranet's read-confirmation features and space permissions to match, after checking with your vendor or implementation partner which of those features the chosen edition provides.
The intranet must not become a place where incidents are first reported or stored. A post saying a machine guard was bypassed does not start the site's incident process, does not replace the permit-to-work system's record of isolation, and does not meet whatever reporting duty the site or its regulator sets. Write this into the intranet policy and the posting guidance: workers report incidents through the site's incident reporting and permit-to-work procedures, and supervisors route anything that looks like an incident into those systems. Where the organization is in scope for NIS2, the reporting clock (early warning within 24 hours, notification within 72 hours, final report within one month under Article 23(4) of Directive (EU) 2022/2555) applies to significant incidents of the entity, whatever channel reported them. An intranet post does not start or satisfy that clock. The intranet only becomes a reporting channel if you design it as one, with its own intake, retention and escalation rules, and you should avoid that unless the operational owner asks for it.
Two checks help keep the boundary clear. First, confirm with the site's health, safety and environment lead which events must never appear in a general space, such as details of an open investigation, personal injury information or anything touching controlled operational data. Second, test the escalation path with a tabletop exercise: a worker posts a near miss in a shift news space, and the supervisor must know where to move it and who closes it. Document the result as a short operating procedure and link it from every safety space, so the boundary is visible to the people who post.
How the rollout moves from pilot plant to every shift
The sequence starts with audiences and plant spaces, settles identity and kiosk access with IT and OT owners, and proves adoption on one site before extending the intranet to every shift and handing it over.
Scope audiences and plant spaces
Work with plant managers, HR and the communications lead to list the worker groups without corporate email, the shifts they work, and the spaces they need: site-wide notices, safety boards, shift news and department areas. Record which groups can post, which can only read, and who moderates each space. The output is a signed audience map and a space inventory that names an owner for every space. Do not start technical work until a plant manager has confirmed the map for the pilot site.
Confirm identity and kiosk model
Meet with the IT directory owner and the OT or plant engineering lead to decide how frontline accounts are created, who sponsors them, how they are removed when someone leaves, and whether shared kiosks use personal logins or a session model. Confirm which directory or identity source is authoritative for plant staff and whether the platform edition supports the chosen single sign-on protocol, which you must verify with the vendor. The output is a written identity decision record reviewed by IT and OT.
Build the network path and access controls
Design how plant devices and kiosks reach the intranet: which network segments are allowed, whether traffic crosses a demilitarized zone or a proxy, and which ports and protocols the OT owner accepts. Set role-based access so kiosk sessions cannot reach administrative functions or sensitive spaces. Confirm the approach with the security team against your OT security program, referring to the ISA/IEC 62443 series for zone and conduit thinking. The output is an approved network diagram and an access matrix tested from a kiosk and a phone.
Pilot on one site with a shift cohort
Select one plant and a representative shift cohort, ideally including supervisors and a shift lead who can post news. Load only the pilot spaces, enable mobile access and the agreed kiosk sessions, and run a short onboarding for supervisors who will moderate. Collect feedback on login friction, notification noise and whether safety notices are seen before shift start. The output is a pilot report listing defects fixed, open items and the changes approved for wider release.
Measure adoption from kiosks and phones
Agree the adoption measures before the pilot ends, such as logins by device type, read rates on mandatory safety notices, and posts per space, and confirm the platform reporting can produce them without exposing personal data beyond what the policy allows. Review the figures with the site manager and the works council or employee representatives where they apply. The output is a short adoption review that states which spaces and device paths are working and which need redesign before extension.
Extend to every shift and site
Roll the approved configuration to the remaining sites in the order the operations team agrees, adding one site or shift group at a time. Repeat the identity, kiosk and access checks at each site because local network rules and directory data often differ. Keep a site-by-site checklist so no shift is onboarded without its safety spaces, mandatory notices and named moderators. The output is a completed deployment log showing each site, its enabled spaces, its device paths and its moderators.
Hand over operations and moderation
Transfer runbooks, the identity decision record, the access matrix and the moderation guidelines to the internal platform team, plant administrators and HR. Train named owners on account lifecycle tasks, backup checks, upgrade notices and escalation paths, and confirm who reviews kiosk session policy each quarter. If DeployOpen supports the platform under a retainer, record the scope of that support in writing. The output is a signed handover pack and a named owner for every operational task, with a dated review date set by your own governance process.
Evidence a manufacturer can show for its intranet controls
This table lists the evidence items a plant or manufacturer can gather to show how its intranet is controlled, what each item demonstrates and which component produces it. Read it as a starting inventory for an assessment, not as a checklist of passing results. DeployOpen prepares and organizes this evidence, but independent auditors and the asset owner's assessors decide whether the controls meet the applicable requirements.
| Evidence item | What it shows | Component that produces it |
|---|---|---|
| Access logs for the intranet | Who signed in, from which device or network, and when, including failed attempts and sessions opened from kiosks or shared accounts | Intranet platform authentication log, reverse proxy logs and the identity provider sign-in log |
| Audit records of administrative actions | Changes to spaces, roles, moderation settings, directory connectors and kiosk policies, with the administrator identity and timestamp | Intranet admin audit log, forwarded to a central log store that the plant security team can read |
| Network diagram of intranet placement | Where the intranet servers sit relative to the corporate network, the DMZ and OT zones, and which flows are permitted between them | Architecture diagram and firewall rule export maintained by the network team, reviewed against the zone model |
| Access list for kiosk and shared accounts | Which shared or kiosk identities exist, which plant or shift uses them, who approved them and when they were last reviewed | Identity provider group and account inventory, plus the approval record kept in the ticketing or ITSM system |
| Record of safety notices with acknowledgements | Which safety notices were published, to which audiences, when, and which workers acknowledged them, with unacknowledged gaps flagged | Intranet notice module or space feed, combined with acknowledgement logs and a periodic export for the safety team |
| Change records for patches and upgrades | Which intranet version and plugins were running, when they changed, what was tested, and who approved the change and any rollback | Change ticket in the ITSM or project system, deployment pipeline logs and the platform release notes used for the change |
| Backup and restore test results | That content, user mappings and configuration can be restored, and when a restore was last tested | Backup job reports and restore test records kept by the operations team |
| Security testing results for the intranet | Which findings were raised against the intranet, their severity, and how and when each was fixed or accepted | Penetration test or vulnerability scan reports and the remediation tracker |
Questions to ask an implementation partner about a plant intranet
Start with the identity model, because it decides most of the rest. Ask the partner how workers with no directory account get a login: whether they use a separate, plant-scoped account store managed by HR or the plant, a badge or PIN flow at the kiosk, or a shared identity that is not tied to a corporate mailbox. Ask which roles gate plant spaces, who can create accounts, how leavers are removed within a set period you agree in writing, and whether an account created for a contractor expires automatically. Ask also which edition of the chosen platform includes the directory connector you need (LDAP, SAML or OIDC). Confirm the answer against the vendor's current edition documentation, not against the partner's memory of it.
Ask how the intranet is separated from operational technology. The relevant reference is the ISA/IEC 62443 series, which asks asset owners to define zones and conduits between business and control networks. Ask the partner to show the zone diagram, the firewall rules that allow only the intranet's outbound paths, and whether any PLC, HMI or historian data is ever pulled into the intranet. For kiosks, ask how sessions are locked after inactivity, whether browser profiles reset after logout, whether USB and printing are restricted, and whether the kiosk can reach only the intranet hostname. Ask for the test results that prove these controls, not a description of them.
Finally, ask about rollout and evidence. Ask how mobile access is delivered (a responsive web app, a vendor app, or a managed device profile), who approves updates to plant-facing pages, and how plant managers are trained to moderate their own spaces. For upgrades, ask how the partner schedules maintenance around shifts and production freezes, whether there is a tested rollback, and how a change is approved before it reaches the plant. For reviews, ask for a current list of network flows, a sample access review export, and the audit logs the platform produces. These records should let your security team answer a network or access review without rebuilding them from memory.
What manufacturers ask before hiring help for a frontline intranet
What drives the cost of a frontline intranet project?
Cost follows the number of sites, the identity work, the content to migrate and the support model you choose. Scope drives most of it: how many plants and shifts need access, whether workers use shared kiosks or personal phones, and how many spaces and news streams must be set up. Identity work adds effort when badge, kiosk or worker accounts sit outside the corporate directory. Costs split into one-time items (planning, configuration, theming, migration, training) and recurring items (hosting, patching, moderation, support). If you choose XWiki, its published pricing lists consulting at 1200 EUR per day for Business or Enterprise support plans and training at 1500 EUR per day (xwiki.com pricing). Ask any partner for a quote that separates these items and states which plant sites and user groups it covers.
Can our internal IT team run a frontline intranet without outside help?
Often yes for the day-to-day running, but the first build usually needs skills that small plant IT teams do not hold in-house. A competent internal team can operate a platform once it is installed, patched and configured, handle user administration and post routine news. Harder work includes hardening the server, integrating with identity sources, designing mobile and kiosk access, and setting up backup and upgrade routines. Assess three things honestly: whether someone can own patching on a fixed cadence, whether the team has directory and certificate experience, and who covers absence. A partner can plan, implement, document and hand over the system, or provide ongoing support under a retainer.
How long does a frontline intranet rollout take across several plants?
The timeline depends mainly on how many sites are in scope and how much identity work is needed before the first worker can log in. A single pilot plant with a clear user list moves faster than a multi-site rollout that must link shift rosters, badge data and kiosk logins. Rollouts commonly run in waves: a pilot site, a fix-and-learn period, then the remaining plants. Ask each vendor for a timeline tied to written milestones: identity decisions, pilot go-live, training per site and handover. Avoid any timeline that does not name the sites, user groups and identity method it assumes.
What do plant managers and IT need to commit to the project?
Plant managers must name local content owners, approve which safety notices and shift news go on shared screens, and free up time for floor staff to attend short onboarding sessions. IT must provide directory or identity access, a decision on how kiosks authenticate, network rules for the intranet hosts, and a named owner for patches and backups. Quality, safety and HR should agree who may publish mandatory notices and who reviews what workers can see. Put these commitments in the statement of work so that a delayed decision is visible early rather than discovered at go-live.
Is a SaaS intranet simpler than a self-hosted one for plant staff?
A SaaS intranet removes server work, which can be a real advantage for a small operation without infrastructure staff. Self-hosting gives more control over where worker data sits, how identity is connected and what happens to kiosk and plant network traffic. Weigh the factors that matter to your sites: whether plant networks can reach a cloud service, whether worker profiles include personal data subject to local rules, how many users you pay for, and how easily you can export content. The right answer depends on your network segmentation and data rules, so confirm them with your security and works council or data protection contacts before deciding.
How does the intranet relate to our shift and maintenance tools?
The intranet should point to shift, maintenance and safety systems rather than replace them. Typical links include a page that shows the current shift plan from your scheduling tool, a link to work orders in your maintenance system, and a news stream for safety notices. Where data must be copied, decide whether it is pushed, pulled through an API or entered by hand, and who owns the source. Keep machine-level data and operational control out of the intranet, since the intranet is a communication layer. Ask any partner which integrations they have delivered before and what they would need from each system's owner, and state which copy is authoritative.
How DeployOpen scopes and supports a plant intranet
A plant intranet starts with a written scope that names the platform, the audiences, the number of plants and shift groups, the mobile and kiosk access paths, and the integrations in or out of the first release. DeployOpen agrees that scope, the deliverables and the timeline in writing before work begins, so the plant team knows what will be built, what is deliberately left out, and what a change request would cost in time. For a platform such as Nextcloud, HumHub or XWiki, the scope should also say which spaces exist on day one, who may post in each, and which news types require moderation before publication.
Network placement is the decision that most often stalls a plant rollout, and it belongs to several owners at once. IT owns the hosting and directory, OT or control-system engineers own the segments where production equipment and shared kiosks sit, and plant managers own the shop-floor rules on what may be displayed and where. Before a server is placed, the team should agree which zone the intranet runs in, which flows cross into the plant network, and whether kiosks reach the platform directly or through a reverse proxy. The ISA/IEC 62443 series is a useful reference for organizing those zone and conduit conversations. Confirm with your OT security lead which requirements apply to your sites before any design is signed off.
Support and upgrades can run as a retainer after go-live, which is a separate agreement from the fixed-scope build. A retainer typically covers patching, module updates, backups checks and help desk escalation, and the reader should ask for its exact response expectations, service windows and exclusions in writing. Plant intranets also need an upgrade window that avoids shift changes and production peaks, so the retainer terms should state how maintenance is scheduled and who approves it on the plant side.
