Introduction

In the last two walkthroughs on secure remote access to SCADA, we focused on setting up a WireGuard server and restricting Ignition Gateway access to be available only through a VPN tunnel.

In this post, we shift focus to the core security practices that form the baseline for every SCADA deployment we undertake. While the depth of implementation often depends on a company’s willingness to invest in securing their industrial infrastructure, even small-scale projects can (and should) cover the essentials.

Here are the critical areas we'll discuss:

• Network Segregation and Isolation
• VPN-Only Remote Access
• Gateway Hardening
• Reverse Proxy Integration

Network Segregation and Isolation

In most industrial automation environments, network segmentation is one of the most important, and most overlooked, foundational security strategies.

Segregation ensures that control systems remain isolated from less-trusted environments, reducing the likelihood and impact of a potential compromise. SCADA systems often control critical infrastructure like energy, water, and manufacturing, where intrusion or downtime can have serious consequences.

By default, flat networks allow all devices on the same subnet to communicate freely, which is convenient, but dangerous. A single compromised technician laptop could reach PLCs, HMIs, or your Ignition Gateway with no barriers.

Recommended Segmentation Architecture:

A secure SCADA setup should be divided into three primary zones:

• Control Zone:
  Includes PLCs, RTUs, sensors, and the Ignition Gateway. This zone should have no direct internet access and only accept traffic from explicitly authorized sources.
• Engineering Zone:
  Composed of engineer laptops, design workstations, and HMIs. Access to the Control Zone must be tightly restricted, ideally via VPN or a jump server.
• DMZ (Demilitarized Zone):
  This acts as a secure buffer between the internal control network and external or semi-trusted networks. In practical terms, a DMZ adds a layer of security by isolating exposed services (e.g., dashboards, MQTT brokers) from critical backend components like the Ignition Gateway or SCADA database.

Example: If you operate two Ignition Gateways, the frontend may be hosted in the DMZ, while the backend (gateway and the database) is safely isolated inside the Control Zone.

Each of these zones should be placed in separate VLANs or subnets, with strict firewall rules defining exactly what traffic is permitted between them.

VPN-Only Remote Access

Remote access is essential in industrial control for engineers, integrators, and supervisors to monitor or maintain SCADA systems off-site. However, exposing SCADA ports to the public internet is a critical vulnerability.

Instead, we enforce VPN-only access. VPNs create an encrypted tunnel between the user and the internal SCADA network, allowing access as if the user is local but without exposing any part of the system to public interfaces.

Benefits:

• No public exposure of Ignition Gateway ports
• End-to-end encrypted communication
• Access control via credentials or cryptographic keys
• VPN IP-level segmentation (only VPN addresses can reach SCADA)

In cases where clients cannot invest in off-the-shelf solutions like Ewon or Tosibox, we deploy WireGuard which is a fast, lightweight VPN that’s ideal for some applications. Though user management (adding/removing peers) is manual, it remains highly secure and scalable for most environments.

VPN-only access is should not be optional because it's a baseline defense. Without it, your SCADA system is effectively exposed to the world.

Gateway Hardening

The Ignition Gateway is the nerve center of any SCADA system, handling configurations, access control, client sessions, control logic, and security. If compromised, the attacker gains broad visibility and control over your operation.

Gateway hardening is the process of reducing this risk by minimizing attack surface and enforcing strict access boundaries.

Best Practices:

• Restrict access to system web pages (/status, /config, /logs) - require login
• Use role-based access control with clearly defined privileges (e.g., Operator, Engineer, Admin)
• Enforce strong password policies and never reuse shared accounts
• Restrict Designer access by disabling "Launch Designer" from the public-facing gateway page
• Use Gateway Network access only where needed

Inductive Automation has already done much of the heavy lifting,  it's up to implementers to follow their Ignition Security Hardening Guide.

Gateway security shouldn’t be a one-time task. It must evolve alongside your system.

Reverse Proxy Integration

A reverse proxy acts as a smart gatekeeper between users and your Ignition Gateway. It filters, logs, routes, and encrypts incoming traffic, enhancing both security and flexibility.

We use Nginx in all deployments as our reverse proxy of choice. When paired with a VPN-only model, Nginx becomes an essential layer for protecting internal services.

Why We Use a Reverse Proxy

Integration with VPN (my application)

All legitimate clients are routed through:

• VPN Subnet: 10.128.0.0/24
• SCADA Gateway VPN IP: 10.128.0.3

Nginx is configured to only allow connections from the VPN subnet. Without a VPN connection, the reverse proxy, and therefore Ignition, is completely inaccessible.

Sample Nginx Configuration

worker_processes  1;

events {
    worker_connections  1024;
}

http {
    include       mime.types;
    default_type  application/octet-stream;

    sendfile        on;
    keepalive_timeout  65;

    # SSL-enabled reverse proxy server for Ignition
    server {
        listen       443 ssl;
        server_name  scada_test.abrouma.com;

        ssl_certificate     /etc/letsencrypt/live/scada_test.abrouma.com/fullchain.pem;
        ssl_certificate_key /etc/letsencrypt/live/scada_test.abrouma.com/privkey.pem;

        ssl_session_cache    shared:SSL:10m;
        ssl_session_timeout  10m;
        ssl_protocols        TLSv1.2 TLSv1.3;
        ssl_ciphers          HIGH:!aNULL:!MD5;
        ssl_prefer_server_ciphers on;

        # Restrict access to VPN subnet
        allow 10.128.0.0/24;
        deny all;

        # Main proxy to Ignition Gateway
        location / {
            proxy_pass http://127.0.0.1:8088;
            proxy_set_header Host $host;
            proxy_set_header X-Real-IP $remote_addr;
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        }

        # Block access to Ignition's config page
        location /web/home {
            deny all;
        }

        # Optional: custom error page
        error_page 403 404 500 502 503 504 /50x.html;
        location = /50x.html {
            root   html;
        }

        # Security headers
        add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
        add_header X-Frame-Options DENY;
        add_header X-Content-Type-Options nosniff;
    }

    # Optional: HTTP to HTTPS redirect (uncomment if needed)
    # server {
    #    listen 80;
    #    server_name scada_test.abrouma.com;
    #    return 301 https://$host$request_uri;
    # }
}

This ensures:

• HTTPS-only traffic
• VPN-only access to the Ignition Gateway
• Configuration paths are protected from unauthorized users

Why I Don’t Use SSL Directly in Ignition

Although Ignition supports built-in SSL, we handle SSL termination in Nginx. Why?

• Let’s Encrypt + Certbot automates certificate renewal
• Easier to apply modern security headers like HSTS and CSP
• Consolidates all incoming traffic through one hardened access point

Internally, Ignition listens only on HTTP (8088). All external access is routed through Nginx with SSL enabled.

On Load Balancing

Nginx can also load balance between multiple Ignition Gateway nodes in high-availability (HA) deployments. However, this requires:

• A Gateway Network configuration
• Multiple Ignition licenses
• A company-level commitment to continuous operation

Conclusion

Whether it’s a multi-million-dollar plant or a compact industrial automation project, security must be intentional.
By integrating network segmentation, VPN-only access, gateway hardening, and a hardened reverse proxy, you create a defense-in-depth architecture for Ignition SCADA systems that balances performance, scalability, and protection. Security be your system's default posture, not an afterthought.