A PC beside a press, a tablet on a packing bench or a terminal in the goods-in area may be used by six people across three shifts. If it fails, the issue is not simply that somebody cannot log in. Production records may stop updating, labels may not print, jobs may be delayed and traceability can quickly become a problem.
To manage shared shopfloor devices properly, treat them as production assets with named ownership, defined users, controlled access and a realistic support plan. The aim is not to force factory staff through office-style processes. It is to keep work moving while reducing the security and operational risks that build up when everyone uses the same machine.
Why shared devices need different rules
Shared devices are common for good reasons. An operator may need access to an MRP screen, digital work instructions or a quality system for a short part of each shift. A warehouse colleague may only need a handheld device to receive stock and print labels. Individual devices and full user accounts are not always practical or proportionate.
The problem starts when the device becomes anonymous. A generic password gets written on a label, the machine stays permanently signed in, and nobody knows who installed an application or changed a setting. That makes day-to-day support slower and creates a serious gap when investigating a quality issue, data loss or suspected cyber incident.
There is also a difference between a shared office PC and a machine-connected computer. A workstation running CAD, ERP or Microsoft 365 can often be updated, replaced or restarted within a planned window. A PC attached to a CNC machine, test rig or production line may depend on old drivers, specialist software and a supplier who only supports a particular configuration. Applying normal IT rules without checking those dependencies can cause the outage you were trying to prevent.
Start with an accurate device and dependency record
You cannot make sensible decisions from a list that says “factory PCs”. Record each shared device, where it is located, what it is used for and who owns the operational decision about it. Include the operating system, installed applications, network connection, peripherals and whether the device connects to machinery, an ERP or MRP system, label printers, file shares or cloud services.
The useful question is not only, “Can we replace this PC?” It is, “What stops if this PC is unavailable for four hours?” A packing terminal may affect despatch but allow production to continue. A programming computer may halt a machine entirely. Those are different risks and deserve different recovery arrangements.
For each device, identify a business owner and a technical owner. The business owner understands the process and approves downtime. The technical owner maintains the device, records changes and coordinates suppliers. In a smaller manufacturer, these may be the operations manager and external IT partner. What matters is that neither role is assumed.
Classify devices by operational impact
A practical classification helps you avoid treating every device as equally urgent. For example, you might separate devices that are production-critical, operationally important, or convenient but non-critical. This classification should influence patching windows, spare-device planning, backup priorities and the speed of support response.
A device that only displays shift information may tolerate a planned reboot. A device that transfers programmes to a machining centre may need a tested maintenance procedure, a known-good replacement and supplier involvement. The sensible approach depends on the process, not on the age of the PC alone.
Give people accountable access without slowing them down
A shared device does not have to mean a shared identity. Where the software allows it, staff should sign in with individual accounts or a quick badge, PIN or approved sign-in method. This gives you a basic audit trail and lets access be removed promptly when someone changes role or leaves.
Some shopfloor applications only support one local account. If that is the constraint, document it rather than pretending it does not exist. Limit what that account can access, use a strong managed password, stop it being used for email or general web browsing, and review the arrangement regularly.
Avoid giving shared users local administrator rights simply because installing a printer or updating a setting is inconvenient. Administrator access can allow software changes, disable security controls and expose saved credentials. Set up a clear route for approved changes instead. It may involve a supervisor, internal IT or your support provider, but it should not depend on whoever happens to know the password.
Physical access matters too. A terminal in an open workshop is vulnerable to accidental damage as well as unauthorised use. Screen locks, secure mounting, sensible cable protection and clear rules for removable USB media are simple controls that can prevent a surprisingly costly disruption.
Separate the shopfloor network from office systems
A shared shopfloor device should not automatically have the same network access as a finance laptop. Network segregation places different systems into controlled zones, so that a compromised terminal cannot freely reach every server, file share or business application.
This is particularly valuable where older operating systems or supplier-managed equipment remain necessary. You may not be able to install the latest security updates on a legacy machine, but you can reduce its exposure. Put it on a restricted network segment, allow only the services it genuinely needs, block unnecessary internet access and control remote connections carefully.
Segregation is not a substitute for replacing unsupported equipment. It is a risk-reduction measure that buys time while you plan a replacement, upgrade or supplier-supported alternative. If a machine PC is essential and unsupported, it should be visible in the business risk register, not quietly ignored because it still starts up each morning.
Patch carefully, but do not leave devices unmanaged
Patching is often where production and IT teams appear to disagree. Operations need stable equipment. IT needs to address vulnerabilities. Both are right, which is why a blanket policy is rarely appropriate.
For standard shared terminals, use centrally managed updates, antivirus or endpoint protection, and scheduled restarts outside active shifts where possible. Check that security updates have installed rather than relying on a green status message. A device that has not restarted for months is not being protected by good intentions.
For machinery-connected or specialist systems, agree a change process with the equipment supplier. Confirm which updates are supported, when testing is required and how to roll back if an application fails. Keep a record of the approved configuration, including drivers and licence details. Before making changes, make sure you have a tested backup or image and a realistic way to restore it.
Do not confuse a backup with a recovery plan. A backup that cannot be restored to compatible hardware, or takes two days to retrieve, may not help when a production line is waiting. Test recovery at intervals that reflect the operational impact of the device.
Control supplier access as tightly as your own access
Remote supplier access can be necessary for diagnostics, software updates and machine support. It is also a common weak point when it is permanent, shared or poorly documented. The right arrangement gives a supplier access only when needed, only to the relevant equipment and with a record of what happened.
Avoid always-on remote-control tools using a single password known by several people. Instead, approve access for a defined period, protect it with multi-factor authentication where the system supports it, and review supplier accounts routinely. If the supplier needs an exception because of old equipment, record the reason, the risk and the compensating controls.
This approach also prevents the familiar problem of suppliers blaming each other. When network paths, access arrangements and support responsibilities are documented, it becomes easier to identify whether an issue lies with the machine, application, network or device.
Build a support model that works across shifts
Shared devices need practical support arrangements, not a ticket process designed only for nine-to-five office work. Put a simple fault-reporting route near critical terminals and make sure staff know what information to provide: device location, error message, affected process and whether production has stopped.
Keep spare peripherals and, where justified, a preconfigured replacement device. A spare label printer or scanner can be far more valuable than an impressive but unused technology policy. For critical workstations, agree whether a standby device, a spare disk image or a supplier-held replacement is the most realistic option.
Review the device estate with operations at least quarterly. Look for recurring faults, devices approaching end of support, accounts that no longer need access and changes to production processes that have altered the risk. This turns reactive fixes into planned decisions with clearer costs and less disruption.
A practical next step for your factory
Choose one shared device that would cause real disruption if it failed tomorrow. Confirm who uses it, what it connects to, whether it is supported, how it is backed up and who can authorise changes. That short exercise usually exposes the gaps worth addressing first.
If you need help assessing shared shopfloor devices, legacy machine PCs or the network around them, Syn-Star can review the arrangement with your operations and IT teams and help build a support plan that protects production without creating unnecessary friction.
