A supplier needs to diagnose a fault on a CNC controller. Your IT provider needs to patch a server. Neither task should require a direct route from the internet into the network that supports production. When you configure jump servers properly, remote users enter through one tightly controlled point, rather than gaining broad access to factory, warehouse or office systems.
For a manufacturer, this is not security theatre. A poorly controlled remote connection can expose CAD files, ERP data and Microsoft 365 accounts. More seriously, it can provide a route towards machinery-connected PCs and production systems that cannot simply be switched off for an update. The aim is to make legitimate support possible while limiting the effect of a compromised password, laptop or supplier account.
What a jump server does – and what it does not
A jump server, sometimes called a bastion host, is a dedicated computer that authorised people connect to first. From that controlled device, they can reach only the systems they have been approved to support. It acts as a checkpoint between remote access and your internal network.
That is different from giving a supplier a permanent VPN connection and hoping their account remains secure. A VPN can still have a place, particularly for employees working remotely, but it should not automatically give every external engineer visibility of the wider network. A jump server supports a more deliberate model: identify the person, confirm why they need access, restrict where they can go and record what they do.
It is not a cure for every legacy-system problem. If an old machine PC has weak local security, a jump server does not fix that weakness. It reduces exposure by ensuring the PC is not directly reachable from the internet and by limiting who can connect to it. The wider design still needs network segregation, backups and a plan for unsupported equipment.
Start with the production dependency, not the server build
The most common mistake is to treat this as an isolated IT project. Before choosing software or building a virtual machine, map what remote support actually involves. Ask which suppliers require access, what equipment they support, when they need access and what could happen if that connection is misused.
For example, a controls supplier may need access only to a specific engineering workstation during an agreed maintenance window. An ERP partner may need access to an application server but should never be able to browse the network containing production equipment. Your internal IT team may need wider rights, but only from managed devices and with additional approval for critical changes.
Document the dependencies as well. A production line may rely on a machine PC, a file share holding job files, a licence server and an ERP or MRP integration. Restricting access without understanding this chain can create its own outage. Equally, discovering that one shared administrator account reaches all four systems should prompt urgent action.
The questions worth settling early are straightforward:
- Who needs remote access, including external suppliers and temporary contractors?
- Which exact systems, ports or applications do they need to use?
- Is access needed routinely, only during faults, or for scheduled maintenance?
- Can production continue if the target system is unavailable while an engineer works on it?
- Who internally approves access, and who removes it when the work is complete?
This exercise often reveals access that nobody actively owns. That is a useful finding, even if it is slightly awkward.
How to configure jump servers safely
A sensible implementation starts with a dedicated, supported operating system. Do not repurpose an ageing general-use PC in the corner of the office. The jump server should have a defined role, be patched promptly, have endpoint protection and be monitored like any other critical security system.
Place it in a separate network segment. It should be reachable from the approved remote-access route, but it should not have unrestricted access to every network. Firewall rules should allow only the necessary connections from the jump server to named target systems. If a supplier supports one engineering workstation, permit that route only. Avoid broad rules that effectively turn the jump server into a corridor with every door left open.
Use named accounts. Every person should sign in with their own identity, including suppliers. Shared credentials make investigations difficult and former contractors surprisingly immortal. Multi-factor authentication should protect remote entry and privileged accounts wherever technically possible. For highly sensitive systems, consider requiring an internal approver to enable access for a limited period.
Limit what users can do once connected. An external supplier may only need remote desktop access to a designated workstation. They may not need clipboard sharing, drive mapping, printing or the ability to transfer files into the network. These features can be useful, but each creates another route for data to leave or malware to arrive. Enable them only where there is a clear operational reason.
Session recording is often valuable for supplier access, particularly where changes affect machinery, recipes, drawings or production integrations. At a minimum, log successful and failed sign-ins, changes to access permissions and connections to critical targets. Recording and logging need to be handled proportionately, with clear internal rules on retention and access to the records.
Keep the jump server for administration. It should not become a convenient everyday desktop, document store or web-browsing machine. The more software, files and casual use it accumulates, the harder it is to secure and support. A purpose-built system is easier to test, rebuild and explain during a customer security review.
Make access temporary where practical
Permanent supplier access is convenient until it becomes an unmanaged risk. For most manufacturing businesses, access enabled for a booked maintenance period or active support case is a better balance. The supplier can still resolve a genuine issue, while an account that is no longer needed is not waiting quietly for the wrong person to find it.
This does require a workable process. If a line has stopped at 2 am, an approval process that depends on one unavailable director is not realistic. Agree an emergency route in advance, identify authorised production or management contacts and ensure every emergency connection is reviewed afterwards.
Protect the route to legacy equipment
Some production systems run older operating systems because the machine supplier has not certified a replacement. Replacing or patching them without planning may jeopardise the machine warranty, software compatibility or output. Leaving them exposed is not an acceptable alternative.
Use network segregation to isolate these devices from office users and the internet. Put a tightly controlled jump server between approved support users and the legacy segment. Prevent the legacy device from initiating unnecessary outbound connections, remove unused services and maintain an offline or otherwise protected recovery option for the machine configuration and related files.
This is compensating control, not a declaration that the device is safe. Record the risk, the reason the system remains in service and the intended replacement or upgrade review date. That is useful operational discipline and can help when customers, insurers or Cyber Essentials preparation work raises questions about unsupported software.
Test the design against a real incident
A jump server that works only in a quiet demonstration is not ready for production. Test the normal connection path with the people who will use it, then test the failures. Can an approved supplier reach only their nominated target? Does access stop when the authorised window ends? Can an internal administrator retrieve useful logs after a failed sign-in? Does a lost supplier laptop create a route into your network?
Also test recovery. Take a backup or build record that lets your IT team recreate the jump server quickly. Protect that information separately from the server itself. If ransomware or a hardware failure affects the access platform, production support should not depend on somebody remembering a configuration from two years ago.
Finally, review access at a fixed interval and after supplier changes, major equipment upgrades or staff departures. A quarterly review is appropriate for many firms, though higher-risk environments may need more frequent checks. Remove accounts, firewall rules and exceptions that no longer have a clear owner.
When a jump server is the right choice
A jump server is particularly useful where several external parties support different systems, where remote access touches production networks, or where customer requirements demand clearer control of privileged access. It can also reduce friction between IT and operations because everyone can see the agreed route for support rather than improvising one during a breakdown.
It may be more than you need if a single managed IT provider accesses only modern, cloud-based office systems through well-controlled identity tools. Conversely, a larger site may need more than one jump server, separated by function or network zone. The right design depends on the value and sensitivity of the systems behind it, not on a generic diagram.
If remote supplier access has grown over time, start by reviewing the accounts, VPNs, remote-control tools and firewall exceptions already in place. Syn-Star can help manufacturing businesses turn that picture into a controlled access design that protects production without making urgent support unnecessarily difficult.
