No. Jump hosts and network firewalls are important, but they are not sufficient on their own to manage risk in legacy manufacturing and OT environments, especially in regulated industries. They reduce some classes of network exposure, but they do not address many common failure modes around configuration, credentials, monitoring, and lifecycle constraints.
What jump hosts and firewalls actually provide
When correctly designed, implemented, and maintained, they can give you:
- Network segmentation: Separation of business IT, DMZ, and OT zones, with explicit rules between them.
- Controlled entry points: A small number of defined paths into sensitive networks instead of broad, flat access.
- Basic traffic filtering: Blocking obviously unauthorized ports, protocols, and destinations.
- Some visibility: Logs of connections traversing the firewall or jump host, assuming logging is enabled, retained, and reviewed.
These are foundational controls, but in legacy environments they leave significant gaps if you rely on them alone.
Key gaps if you rely only on jump hosts and firewalls
Common gaps you should assume exist unless you have explicitly designed and validated controls around them:
- Weak identity and access management: Shared accounts, local users on the jump host, static VPN credentials, and lack of strong authentication are still very common. Compromising one credential can open broad access.
- Limited authorization granularity: Firewalls and jump hosts typically control where you can connect, not what you can do once connected (e.g., SCADA admin vs. read-only, MES configuration vs. operator use).
- Insufficient monitoring and alerting: Logs may exist but are often not centralized, correlated, or actively reviewed. Suspicious activities (e.g., out-of-hours access, repeated failed logins, large configuration pulls) can easily go unnoticed.
- Configuration drift and rule sprawl: Over time, firewall rules and jump host access lists tend to accumulate exceptions. In brownfield plants, change control around network rules is often weaker than application change control.
- Legacy protocols and insecure services: Firewalls do not fix fundamentally insecure protocols (e.g., unauthenticated vendor protocols, clear-text management interfaces, legacy SMB). They may simply allow or block them.
- Insider and supply chain risk: Once a user reaches the jump host, an overly permissive configuration can allow them to pivot broadly across OT, MES, QMS, or engineering systems.
- Device and application hardening: Firewalls do not address outdated OS versions, unpatched HMIs, legacy PLCs, or unmaintained application servers that are common in long-lifecycle equipment.
Practical additional controls for legacy OT and MES environments
In a regulated, brownfield context, you usually need a layered approach. Examples of controls that commonly sit alongside jump hosts and firewalls:
- Network design and segmentation discipline:
- Clear zoning between corporate IT, DMZ, OT control, safety, and lab/test environments.
- Documented and justified flows between zones, with change-controlled rule sets.
- Avoid “temporary” exceptions that become permanent without review.
- Strong access control around jump hosts:
- Unique accounts tied to individuals; no generic or shared credentials.
- Multi-factor authentication where feasible, especially for remote and vendor access.
- Role-based access, with least-privilege profiles for operations, engineering, and vendors.
- Session control and recording for critical systems:
- Session logging or recording for remote access that can modify PLCs, DCS logic, MES configuration, or QMS infrastructure.
- Time-bound access approvals for vendors or elevated support tickets, integrated with change control.
- Endpoint hardening and patching strategy:
- Defined, validated patching policies for jump hosts and OT-facing servers, aligned with downtime windows and qualification needs.
- Application whitelisting or at least malware protection on jump hosts that interface between IT and OT.
- Monitoring, detection, and response:
- Centralized logging from firewalls, jump hosts, VPNs, and key OT servers.
- Defined alert thresholds and responsible roles for investigating unusual access patterns.
- Periodic review of logs to support audits, root cause analysis, and incident investigations.
- Backup and recovery aligned to OT reality:
- Regular, tested backups of jump host configurations, firewall rules, and critical OT system configs.
- Documented and periodically tested recovery procedures that account for validation and qualification constraints.
- Change control and traceability:
- Change records for firewall rules, VPN profiles, and jump host configuration changes.
- Risk assessments and, when needed, re-validation or re-qualification steps for changes that affect regulated systems or data flows.
Legacy and brownfield constraints you must account for
In many plants, especially in aerospace, pharma, and medical devices, you will face constraints that limit how far you can modernize security controls:
- Unpatchable or unsupported equipment: Some PLCs, HMIs, analyzers, or legacy MES nodes cannot be updated without re-qualification, vendor involvement, or unacceptable downtime. For these, network and access controls become the primary mitigation, but must be carefully designed and documented.
- Interdependencies with validated systems: Changing authentication methods, VPN clients, or inspection devices on the path to a validated system may trigger re-validation. That cost and lead time often slows security improvement projects.
- Limited maintenance windows: Plants with high utilization and complex change windows cannot tolerate frequent reboots or prolonged outages to deploy security updates or network redesigns.
- Integration debt: Firewalls and jump hosts often sit in the middle of complex, poorly documented integrations among MES, ERP, historians, and lab systems. Aggressive changes can break fragile, vendor-specific protocols.
These realities are why “full replacement” strategies (e.g., ripping out all legacy controls and re-architecting everything around a new OT security stack) often fail: qualification burden, downtime risk, and complexity make incremental, layered approaches much more practical.
How to evaluate whether your current setup is adequate
Rather than asking whether jump hosts and firewalls are “enough” in the abstract, assess them in context:
- Risk-based view: What critical assets are reachable beyond the firewall and jump host (safety systems, release-decision data, batch records, NC/CAPA systems)? What is the impact if they are misused or unavailable?
- Assumed breach perspective: If an attacker or malicious insider obtains access to the jump host, how far can they go? What additional barriers, monitoring, or approvals exist?
- Evidence for audits and investigations: Can you reliably show who accessed what, when, and from where, for key OT and QC systems?
- Change and lifecycle management: Are changes to firewall rules, VPN access, and jump host configurations documented, reviewed, and tied to risk assessments and validation where required?
Summary
Jump hosts and network firewalls are necessary components of a secure architecture for legacy manufacturing environments, but they are rarely sufficient by themselves. In regulated, brownfield plants, they must be part of a layered strategy that includes strong identity and access management, endpoint hardening, monitoring, change control, backup and recovery, and careful accommodation of long-lived, hard-to-update equipment. How effective they are depends heavily on your actual design, configuration quality, validation state, and ongoing governance.
