Cybersecurity Hardening for Legacy B&R CP1584 Systems

Overview

This guide provides actionable, step-by-step procedures for hardening a B&R X20CP1584 PLC system when you have no OEM support, no original project documentation, and a controller that cannot be fully patched. The CP1584 runs Automation Runtime (AR) 4.x on a VxWorks kernel — it maxes out at AR R4.93, which leaves 17+ known CVEs permanently unpatchable. Network isolation and defense-in-depth are not optional best practices — they are survival requirements.

Audience: An automation engineer maintaining one or more CP1584-based machines from defunct OEMs, who needs to secure the system without vendor support, formal IEC 62443 certification budgets, or a dedicated OT security team.

Threat model: The CP1584 was not designed with modern cybersecurity in mind. It lacks signed firmware verification (on AR 4.x), has no built-in firewall, ships with multiple open network services by default, and its underlying VxWorks kernel has known unpatched vulnerabilities. An attacker on the same network segment can crash the PLC (CVE-2025-3450, CVE-2021-22275), intercept communications (CVE-2024-5800, CVE-2024-8603), or bypass authentication (CVE-2023-1617, CVE-2025-3449).

Related Documents

1. The Hardening Problem: Why CP1584 Is Different

1.1 Unpatchable by Design

The CP1584 is an end-of-life CPU limited to AR 4.x. AR R4.93 is the final release. No further security patches will be produced for this platform. The following categories of vulnerabilities are permanently unpatchable:

Bottom line: 20+ CVEs remain open on AR 4.x (even at R4.93). The only defense is network isolation. See ar-rtos.md for the complete CVE table.

2026 Advisory Wave (Jan 2026): Three new advisories were published in January 2026: SA26P001 (PVI credential leak into logfile), SA25P004 (AS insufficient server certificate validation), and SA25P005 (ANSL server flooding DoS — already patched in R4.93). SA26P001 is notable because it affects the PVI client on the engineering PC, not the PLC itself — an authenticated attacker can cause PVI to log sensitive data (including connection credentials) to the PVI log file. Upgrade PVI to 6.5 (shipped with AS 6.5) to remediate.

1.2 Service Surface Attack Map

Every network service on the CP1584 is an attack surface. Map them before hardening:

1.3 IEC 62443 Context

IEC 62443 is the international standard for industrial automation cybersecurity. While full certification is unrealistic for legacy equipment, the standard’s core concepts — zones and conduits — provide the right architectural framework:

• Zone: A group of assets that share the same security requirements. The CP1584 and its directly connected I/O form one zone.
• Conduit: A controlled communication path between zones (a firewall rule, a VPN tunnel, a one-way diode).

Even without formal certification, applying IEC 62443 zone/conduit thinking to a legacy CP1584 system dramatically improves its security posture.

2. Hardening Checklist (By Priority)

Use this checklist in order. Each step builds on the previous.

Phase 1: Immediate Actions (Do Today)

• 2.1 Update firmware to AR R4.93 (patches the worst CVEs)
• 2.2 Identify and document all open ports on the CP1584
• 2.3 Disable unnecessary services
• 2.4 Change all default/known credentials
• 2.5 Block PLC from all networks except the control VLAN

Phase 2: Network Isolation (Do This Week)

• 2.6 Implement zone/conduit network architecture
• 2.7 Configure firewall rules per Section 4
• 2.8 Set up a dedicated maintenance VLAN
• 2.9 Disable ANSL discovery broadcasts on production networks

Phase 3: Service Hardening (Do This Month)

• 2.10 Secure OPC-UA with certificates and strong policies
• 2.11 Disable or restrict SDM to maintenance windows only
• 2.12 Disable FTP; use SCP/SFTP for file transfers
• 2.13 Update VC4 if VNC is used
• 2.14 Secure SNMP or disable it
• 2.15 Secure NTP source

Phase 4: Monitoring and Maintenance (Ongoing)

• 2.16 Set up network monitoring for anomalous traffic to/from the PLC
• 2.17 Subscribe to B&R security advisories
• 2.18 Document and periodically audit all changes
• 2.19 Plan migration timeline to patchable hardware

3. Step-by-Step Hardening Procedures

3.1 Update Firmware to AR R4.93

This is the single most important hardening step. AR R4.93 patches:

• CVE-2025-11044 (ANSL DoS — can permanently crash the PLC via network packets)
• CVE-2025-3450 (SDM DoS — crashes the PLC via crafted SDM request)
• CVE-2022-4286 (SDM reflected XSS)
• CVE-2023-3242 (portmapper DoS)

Procedure:

1. Verify current AR version:

   - Connect to serial console (IF1, 115200 baud) and watch boot screen
   - OR: check via SDM web interface at http://<PLC_IP>/sdm
   - OR: use Automation Studio: Online > Device Information
   - OR: FTP to C:\ and examine SysDir\*.cfg files for version strings
   

2. Obtain AR R4.93 upgrade:

   • Install Automation Studio 4.12 (latest AS4 — see firmware-version-mgmt.md)
   • Download AR R4.93 upgrade via Tools > Upgrades in AS
   • If no AS license: use the 90-day evaluation license. The runtime transfer does not require a permanent license on the engineering PC

3. Backup the current system:

   - Image the CF card: dd if=/dev/sdX of=cp1584_backup_$(date +%Y%m%d).img bs=4M
   - FTP backup of user partition (F:\)
   - Screenshot all SDM pages
   - Export any retentive data (see [retentive-data.md](retentive-data.md))
   

4. Perform the upgrade:

   • Follow the firmware update procedure in firmware.md
   • The upgrade replaces the AR OS files on the CF card while preserving user partition data
   • Plan for 15-30 minutes of downtime
   • Verify the PLC boots to RUN state with AR 4.93 after update

5. Post-upgrade verification:

   • Confirm AR version in SDM
   • Verify all cyclic tasks are running
   • Check for any new warnings or errors in the AR log
   • Re-test machine operation

Warning: Never skip the CF card backup. If the upgrade fails, the backup image is your only recovery path. See bootloader-recovery.md for recovery procedures.

3.2 Identify Open Ports and Services

Scan the CP1584 from a workstation on the same subnet:

nmap -sV -p- --open -T4 <PLC_IP>

Expected results for a default AR R4.93 installation:

PORT      STATE  SERVICE    VERSION
21/tcp    open   ftp        B&R Automation FTP (AR 4.93)
80/tcp    open   http       B&R Automation WebServer / SDM
11169/tcp open   unknown    B&R ANSL / PVI Manager
30303/udp open   unknown    B&R ANSL Discovery
123/udp   open   ntp        (if NTP configured)

Document every port you find. Compare against the service surface map in Section 1.2. Any port not in that table is unexpected and requires investigation.

3.3 Disable Unnecessary Services

FTP Server — Disable or Restrict:

The FTP server uses weak TLS (CVE-2024-5800, CVE-2024-8603). Even with TLS enabled, communications may be decryptable.

• Best: Block port 21 at the firewall entirely. Use FTP only during maintenance windows with firewall rules temporarily opened.
• Alternative: Change FTP credentials from defaults (br/br) to strong credentials. Restrict FTP access to the maintenance VLAN only.

SDM Web Server — Restrict to Maintenance Windows:

SDM has multiple unpatchable vulnerabilities on AR 4.x (session takeover, XSS, CSV injection from SA25P003). SA2025P003 (Oct 2025) documents additional SDM CVEs requiring AR >= 6.5. Even after updating to R4.93, the SDM web interface should be treated as hostile if exposed to any network beyond the control VLAN.

• Block port 80/443 at the firewall during normal operation
• Temporarily allow access during scheduled maintenance windows
• Never expose SDM to the office network or internet

ANSL Discovery (UDP 30303) — Cannot Be Disabled:

The ANSL discovery broadcast cannot be disabled in AR 4.x. It reveals the PLC’s IP address, serial number, firmware version, and device name to anyone on the network segment. Network segmentation is the only mitigation — put the PLC on a dedicated VLAN that engineering and HMI devices share, but no other network segment can reach.

INA2000 (TCP 11160) — Disable if Possible:

INA2000 is a legacy protocol. PVI 6.x (AS 6.x) dropped support for it. If no legacy tools require INA2000:

• In Automation Studio, the INA2000 transport is configured per connection in the PVI Manager setup
• On the PLC side, the INA2000 port is always open if the AR version supports it
• Firewall block on port 11160 is the mitigation

VNC (TCP 5900/5800) — Disable if Not Needed:

• VNC is only needed for remote HMI viewing
• CVE-2023-1617 allows authentication bypass on older VC4 versions
• If VNC is not needed for daily operation, block port 5900/5800 at the firewall
• If VNC is required, update VC4 to the latest version and restrict access to HMI subnets only

SNMP — Disable if Not Used:

• SNMP on AR 4.x often uses default community strings (public, private)
• SNMP exposes CPU temperature, memory usage, module status — useful for attackers planning attacks
• If not used for monitoring, block UDP 161/162 at the firewall
• If used, change community strings to strong values and restrict to monitoring server IPs

3.4 Change All Default Credentials

B&R controllers have no factory-level passwords — all credentials are application-defined (see access-recovery.md). However, common defaults exist in the field:

Credential management without AS project:

Most credentials are baked into the AS project configuration. If you do not have the original project, you cannot change AS Online Login, OPC-UA user roles, or mapp User passwords without rebuilding the project. For these, network isolation is your primary defense.

FTP credentials and SNMP community strings can sometimes be changed via the CF card configuration files without the full AS project — see config-file-formats.md.

3.5 Implement Zone/Conduit Network Architecture

Apply IEC 62443 zone/conduit thinking to create a network architecture that isolates the CP1584 from threats.

Recommended Three-Zone Architecture:

+---------------------+     Firewall      +--------------------+     Firewall     +------------------+
|   OFFICE / IT ZONE  |================== |  INDUSTRIAL DMZ    | ================ |  CONTROL ZONE    |
|                     |  (Block ALL PLC    |  (SCADA server,    |  (Allow only     |  (CP1584, I/O,    |
|  - Workstations     |   traffic FROM    |   historian,       |   protocol-       |   HMI panels,     |
|  - Internet         |   this zone)      |   engineering PC)  |   specific traffic|   drives,         |
|  - Guest WiFi       |                   |                    |  FROM DMZ only)   |   field devices)  |
+---------------------+                   +--------------------+                   +------------------+
                                                                 |
                                                    Firewall blocks ALL
                                                    traffic from Office
                                                    and Internet zones

Zone Definitions:

Conduit Rules (Control Zone Inbound):

Conduit Rules (Control Zone Outbound):

3.6 Firewall Implementation

Option A: Managed Industrial Switch with ACLs

Most industrial environments have managed switches (Cisco, Hirschmann, Moxa, B&R X20SW). Configure VLANs and ACLs:

# Example VLAN configuration (Hirschmann/Phoenix Contact syntax)

# Control Zone VLAN
vlan 10
  name "CONTROL_ZONE"
  untagged 1-12
  tagged 25

# Industrial DMZ VLAN
vlan 20
  name "INDUSTRIAL_DMZ"
  untagged 13-20
  tagged 25

# Inter-VLAN ACL: DMZ -> Control Zone
access-list DMZ_TO_CONTROL
  permit tcp any any eq 4840       # OPC-UA
  permit tcp any any eq 11169      # ANSL
  permit udp any any eq 123        # NTP
  deny ip any any                  # Block everything else

# Apply ACL to VLAN 20 interface
interface vlan 20
  ip access-group DMZ_TO_CONTROL in

# Port 21 (FTP) and 80 (SDM/HTTP) are BLOCKED by default
# Temporarily permit during maintenance:
#   permit tcp <maintenance_ip> any eq 80
#   permit tcp <maintenance_ip> any eq 21

Option B: Dedicated Industrial Firewall

If a dedicated firewall appliance is available (Fortinet FortiGate, Cisco ISA, Claroty, Nozomi):

# Control Zone -> DMZ firewall policy
policy CONTROL_TO_DMZ
  source-zone: CONTROL
  dest-zone: DMZ
  service: NTP, PVI-Callback
  action: ALLOW
  logging: all

# DMZ -> Control Zone firewall policy
policy DMZ_TO_CONTROL
  source-zone: DMZ
  dest-zone: CONTROL
  service: OPC-UA, ANSL, NTP
  source-address: [SCADA_Server_IP, Engineering_PC_IP, NTP_Server_IP]
  action: ALLOW
  logging: all

# Maintenance window policy (disabled by default)
policy MAINTENANCE_DMZ_TO_CONTROL
  source-zone: DMZ
  dest-zone: CONTROL
  service: HTTP, FTP
  source-address: [Engineering_PC_IP]
  schedule: maintenance_window
  action: ALLOW
  logging: all
  enable: false  # Enable only during scheduled maintenance

Option C: PC-Based Firewall (Minimal Budget)

If no managed switch or firewall appliance exists, use a Linux-based firewall between the office and control networks:

# Install on a dual-NIC Linux box (one NIC to office, one to control network)
apt install nftables

# /etc/nftables.conf
#!/usr/sbin/nft -f

flush ruleset

table inet filter {
  # Control Zone interface (facing PLCs)
  chain input_control {
    type filter hook input priority 0; policy drop;

    # Allow established/related connections
    ct state established,related accept

    # Allow NTP
    udp dport 123 accept

    # Allow ICMP for diagnostics
    ip protocol icmp accept

    # Drop everything else
    drop
  }

  # DMZ interface (facing engineering workstations)
  chain input_dmz {
    type filter hook input priority 0; policy drop;

    ct state established,related accept

    # Allow SSH to firewall itself for management
    tcp dport 22 accept

    drop
  }

  # Forward from DMZ to Control Zone
  chain forward {
    type filter hook forward priority 0; policy drop;

    # Allow DMZ -> Control: OPC-UA
    iifname "eth1" oifname "eth0" tcp dport 4840 accept

    # Allow DMZ -> Control: ANSL
    iifname "eth1" oifname "eth0" tcp dport 11169 accept

    # Allow DMZ -> Control: NTP
    iifname "eth1" oifname "eth0" udp dport 123 accept

    # Allow Control -> DMZ: NTP outbound
    iifname "eth0" oifname "eth1" udp sport 123 accept

    # Allow Control -> DMZ: PVI callback
    iifname "eth0" oifname "eth1" tcp sport 11160 accept

    # Block everything else
    drop
  }
}

3.7 Secure OPC-UA Configuration

OPC-UA is the primary data exchange protocol for B&R systems. If the OPC-UA server is enabled on the CP1584, secure it:

Certificate Management:

1. Generate a self-signed certificate for the PLC (if one doesn’t exist — check via SDM or FTP to F:\ or C:\AS\)
2. Copy the PLC’s certificate to all OPC-UA clients
3. Generate client certificates and trust them on the PLC side (requires AS project modification — see opcua.md)

Security Policy Selection (if modifiable):

If you cannot modify the OPC-UA configuration (no AS project), enforce security at the network level:

• Allow OPC-UA (port 4840) only from trusted SCADA/HMI servers
• Block OPC-UA from all other networks
• Monitor OPC-UA traffic for unexpected connections using network monitoring tools

3.8 SDM Hardening (Mitigate, Don’t Patch)

Since SDM vulnerabilities cannot be fully patched on AR 4.x:

1. Block SDM at the firewall during normal production. Port 80/443 to the CP1584 should be blocked by default.
2. When SDM access is needed for diagnostics, use a temporary firewall rule that allows HTTP/HTTPS only from a specific maintenance workstation IP, and close the rule immediately after the maintenance window.
3. Never access SDM from the office network or over WiFi. Always use a wired connection on the DMZ or a maintenance VLAN.
4. Clear browser session after SDM access — CVE-2025-3449 (predictable session ID) means an attacker who can guess the session ID could hijack your SDM session.
5. Do not click links to SDM — CVE-2025-3448 (reflected XSS) could execute JavaScript in your browser if you follow a crafted link.

3.9 FTP Alternatives

FTP on AR 4.x uses weak TLS that may be decryptable. Alternatives:

For File Backup (Pull from PLC):

• Use FTP only from the maintenance VLAN with firewall temporarily opened
• Accept that the transfer may be observable on the network
• Transfer only configuration files, not sensitive production data

For File Push (To PLC):

• If modifying CF card contents is necessary, consider:
  1. Physical CF card swap (most secure — remove card, write on isolated workstation, reinsert)
  2. FTP during maintenance window with firewall rules temporarily opened
  3. Automation Studio file transfer over ANSL (encrypted within the PVI protocol layer)

SCP/SFTP Alternative:

• AR 4.x does not natively support SSH/SCP/SFTP
• If secure file transfer is critical, consider building a small ARM/Linux gateway box that runs an SSH server and relays files to the PLC via FTP (accepting the FTP weakness only on the local control network segment)

3.10 NTP Hardening

Use a trusted internal NTP server, not internet NTP pools:

1. Designate an internal server (in the DMZ) as the NTP source for all control zone devices
2. That server synchronizes with upstream internet NTP servers
3. The CP1584 synchronizes only with the internal server
4. Firewall: allow UDP 123 only from the internal NTP server to the CP1584

Why: An attacker who can spoof NTP responses could shift the PLC’s clock, causing time-based logic to malfunction, corrupting timestamp-based alarm analysis, or invalidating certificate validity periods.

3.11 Engineering Workstation Hardening

The engineering workstation running Automation Studio and PVI is a high-value target:

CVE-2025-11043 (AS Certificate Validation Bypass): Automation Studio does not properly validate TLS certificates. An attacker on the network could impersonate the PLC during AS online operations.

CVE-2026-0936 (PVI Logfile Credential Leak): PVI logs credentials in plaintext log files.

Mitigations:

1. Upgrade Automation Studio to the latest version — AS 4.12.9+ includes the latest patches for AS-side vulnerabilities
2. Run AS only on the DMZ network — never on the office network or WiFi
3. PVI logfile security:
   • Locate PVI log files on the engineering workstation (typically in %APPDATA%\BR\Automation\ or similar)
   • Set filesystem permissions so only the engineering user account can read them
   • Periodically clean log files that contain credentials
   • If possible, disable PVI logging or set it to minimal level
4. AS certificate validation: Until B&R fully patches CVE-2025-11043, be aware that AS may accept fraudulent certificates during online operations. Only connect to PLCs on the isolated control network where man-in-the-middle attacks are not feasible.

4. Complete Firewall Rule Reference

This is the authoritative firewall rule set for a hardened CP1584 (AR R4.93) installation. Adapt IP addresses and VLANs to your network.

4.1 Inbound Rules to CP1584

# REQUIRED (Production)
ALLOW  TCP  11169  from [SCADA/HMI subnet]     # ANSL - OPC-UA FX, AS online
ALLOW  TCP  4840   from [SCADA/HMI subnet]     # OPC-UA - if server enabled
ALLOW  UDP  123    from [NTP server IP]         # NTP time sync
ALLOW  ICMP        from [DMZ subnet]           # Ping for diagnostics

# OPTIONAL (With Restrictions)
ALLOW  TCP  80     from [Maintenance IP]       # SDM - maintenance windows only
ALLOW  TCP  443    from [Maintenance IP]       # SDM HTTPS - maintenance windows only
ALLOW  TCP  21     from [Maintenance IP]       # FTP - maintenance windows only
ALLOW  TCP  5900   from [HMI panel IPs]        # VNC - only from authorized panels
ALLOW  UDP  161    from [Monitoring server IP]  # SNMP - only from authorized collector

# BLOCK (Always)
BLOCK  TCP  21     from ALL (except maintenance) # FTP insecure
BLOCK  TCP  5900   from ALL (except HMI panels)  # VNC insecure
BLOCK  UDP  30303  from ALL (external zones)     # ANSL discovery - control zone only
BLOCK  ALL         from [Office/IT/Guest]        # Zero trust for non-control networks
BLOCK  ALL         from ANY (external/Internet)  # Never expose PLC to internet

4.2 Outbound Rules from CP1584

# ALLOW
ALLOW  UDP  123    to [NTP server IP]           # NTP time sync
ALLOW  TCP  11160  to [PVI Manager IP]          # PVI callbacks (if used)

# BLOCK
BLOCK  ALL         to ANY                       # PLC should not initiate external connections

4.3 Inter-VLAN Rules (If Using VLANs)

# Office VLAN -> Control Zone VLAN
BLOCK  ALL

# Industrial DMZ VLAN -> Control Zone VLAN
ALLOW  TCP  4840   (OPC-UA)
ALLOW  TCP  11169  (ANSL)
ALLOW  UDP  123    (NTP)
BLOCK  ALL

# Control Zone VLAN -> Industrial DMZ VLAN
ALLOW  UDP  123    (NTP responses)
ALLOW  TCP  11160  (PVI callback)
BLOCK  ALL

5. Network Monitoring for Anomaly Detection

Even with firewall rules in place, monitoring provides detection for when (not if) something goes wrong.

5.1 What to Monitor

5.2 Monitoring Tools

Passive (Recommended for Legacy Systems):

# Simple port scan detection using tcpdump
# Run on the DMZ firewall or a SPAN port
tcpdump -i eth0 -n 'host <PLC_IP> and not (udp port 123 or tcp port 4840 or tcp port 11169)'
# Alerts on any traffic to PLC that isn't OPC-UA, ANSL, or NTP

# Log ANSL discovery probes (watch for scanning)
tcpdump -i eth0 -n 'udp port 30303 or udp port 11169'

Active (If Budget Allows):

• Open-source: Zeek (formerly Bro) network security monitor
• Industrial-specific: Wireshark with OPC-UA and POWERLINK dissectors
• Commercial: Claroty, Nozomi Networks, Dragos (if budget allows)
• For Python-based custom monitoring: see python-diagnostics.md

5.3 Automated Alerting Script

#!/usr/bin/env python3
"""
cp1584_network_monitor.py - Monitors network traffic to/from a B&R CP1584
for anomalous connections. Run on a SPAN port or firewall log collector.
"""

import subprocess
import time
import logging
from datetime import datetime

logging.basicConfig(
    filename='/var/log/cp1584_monitor.log',
    level=logging.INFO,
    format='%(asctime)s - %(levelname)s - %(message)s'
)

PLC_IP = '192.168.10.5'
KNOWN_SOURCES = {
    '192.168.20.10': 'SCADA-Server',
    '192.168.20.11': 'Engineering-PC',
    '192.168.20.20': 'NTP-Server',
    '192.168.10.100': 'HMI-Panel-1',
}

ALLOWED_PORTS = {4840, 11169, 123}  # OPC-UA, ANSL, NTP
ALERT_COOLDOWN = 300  # seconds between repeated alerts

last_alert = {}

def check_connections():
    try:
        result = subprocess.run(
            ['ss', '-tn', f'dest', PLC_IP],
            capture_output=True, text=True, timeout=10
        )
        for line in result.stdout.splitlines()[1:]:  # Skip header
            parts = line.split()
            if len(parts) < 4:
                continue
            source = parts[4].rsplit(':', 1)[0]
            dest_port = parts[3].rsplit(':', 1)[1]
            state = parts[1]

            if dest_port.isdigit() and int(dest_port) not in ALLOWED_PORTS:
                hostname = KNOWN_SOURCES.get(source, 'UNKNOWN')
                if hostname == 'UNKNOWN' or state != 'ESTAB':
                    alert_key = f"{source}:{dest_port}"
                    now = time.time()
                    if alert_key not in last_alert or (now - last_alert[alert_key]) > ALERT_COOLDOWN:
                        msg = f"SUSPICIOUS: {source} ({hostname}) -> {PLC_IP}:{dest_port} [{state}]"
                        logging.warning(msg)
                        print(msg)
                        last_alert[alert_key] = now
    except Exception as e:
        logging.error(f"Monitoring error: {e}")

if __name__ == '__main__':
    logging.info(f"CP1584 network monitor started for {PLC_IP}")
    while True:
        check_connections()
        time.sleep(60)

6. Physical Security Checklist

Network security is meaningless if someone can walk up to the PLC with a laptop:

• Control cabinet locked with key access limited to authorized personnel
• CF card not easily removable without opening the cabinet (it should be behind the cabinet door)
• Serial console port (IF1) not accessible from outside the cabinet
• DIP switches not accessible without opening the cabinet
• USB port — CP1584 has a USB port on the front. Consider physically blocking or disabling it if not needed (some firmware versions allow USB disable)
• Network cables secured — label all cables; verify no unauthorized taps or switches are inserted
• Cabinet grounding and bonding verified — see grounding-emc.md for procedures

7. Secure Remote Access

If remote maintenance access to the CP1584 is required (e.g., you need to connect from off-site):

7.1 Recommended Architecture

Remote Engineer (Home/Office)
    |
    | VPN Tunnel (WireGuard / OpenVPN / IPsec)
    v
[Industrial DMZ - Jump Host / Bastion]
    |
    | Direct connection on control VLAN
    v
CP1584

Critical rules:

1. Never expose the CP1584 directly to the internet. No port forwarding, no dynamic DNS to PLC ports.
2. VPN is mandatory. All remote access goes through a VPN concentrator in the DMZ.
3. Jump host / bastion. Remote engineers connect to a bastion host in the DMZ, then from there to the PLC. The bastion should log all sessions.
4. MFA on VPN. Require multi-factor authentication for VPN connections.
5. Session timeout. VPN sessions should time out after a configurable period of inactivity.
6. Maintenance window enforcement. Remote access should only be possible during scheduled maintenance windows.

7.2 VPN Implementation (WireGuard Example)

# On the DMZ bastion/gateway
apt install wireguard

# /etc/wireguard/wg0.conf
[Interface]
Address = 10.10.99.1/24
ListenPort = 51820
PrivateKey = <gateway_private_key>

[Peer]
# Remote engineer
PublicKey = <engineer_public_key>
AllowedIPs = 10.10.99.2/32

[Peer]
# Additional engineer
PublicKey = <engineer2_public_key>
AllowedIPs = 10.10.99.3/32

# On the remote engineer's laptop
# /etc/wireguard/wg0.conf
[Interface]
Address = 10.10.99.2/24
PrivateKey = <engineer_private_key>
DNS = 10.10.20.1  # Internal DNS

[Peer]
PublicKey = <gateway_public_key>
Endpoint = <dmz_gateway_public_ip>:51820
AllowedIPs = 10.10.20.0/24, 10.10.10.0/24  # DMZ and Control subnets
PersistentKeepalive = 25

The engineer then connects to the CP1584 via its control zone IP (e.g., 10.10.10.5) through the VPN tunnel. The gateway firewall already permits DMZ -> Control Zone traffic for ANSL, OPC-UA, and NTP.

8. Incident Response for CP1584

8.1 Signs of Compromise

8.2 Recovery Procedure

1. Isolate: Block all network traffic to/from the CP1584 at the nearest switch or firewall
2. Preserve: Capture any available network logs, SDM snapshots, AR logs before rebooting
3. Recover: Restore the CF card from the known-good backup image (dd backup)
4. Verify: After boot, compare all files on the restored CF card against the backup checksums
5. Analyze: Determine the attack vector before reconnecting to the network
6. Harden: Apply any additional firewall rules or service restrictions identified during analysis
7. Report: If the attack caused safety concerns, document thoroughly for compliance

8.3 CF Card Backup Integrity Verification

# Create checksums of CF card backup
sha256sum cp1584_backup_20260710.img > cp1584_backup_20260710.sha256

# Verify backup integrity before restore
sha256sum -c cp1584_backup_20260710.sha256

# Verify restored card matches backup
dd if=/dev/sdX bs=4M | sha256sum
# Compare to: sha256sum cp1584_backup_20260710.img

9. B&R Security Advisory Monitoring

9.1 Subscription Sources

9.2 Security Advisory Timeline (2024-2026)

This timeline tracks all B&R security advisories that affect CP1584 / AR 4.x systems. Advisories marked “Patched in R4.93” are addressed by updating to the latest AR 4.x. All others remain permanently open.

9.3 CRA 2027 Compliance Assessment

The EU Cyber Resilience Act (CRA) takes full effect December 2027. Products with digital elements placed on the EU market must meet cybersecurity requirements including vulnerability handling, security updates, and incident reporting.

CP1584 CRA Assessment:

Implication: Machines containing CP1584 controllers cannot meet CRA requirements as-is. The only path to CRA compliance is migration to patchable B&R hardware (AR 6.x) or a non-B&R platform. See remanufacturing.md for migration planning. The EU Machinery Regulation (MR) also takes effect January 2027, compounding the compliance urgency.

Key Findings

1. CP1584 on AR 4.x is permanently unpatchable. B&R has ended-of-life for AR 4.x and the CP1584 cannot run AR 5.x or 6.x. All 20+ known CVEs will remain open for the lifetime of these controllers.

2. The attack surface is broad. Default-enabled services include FTP (unencrypted), HTTP/SDM web server, OPC-UA, SNMP, POWERLINK, ANSL, and the PVI portmapper. Many use weak or default authentication.

3. Network isolation is the most effective defense. Since patching is impossible, placing the CP1584 on an isolated VLAN with a firewall blocking all inbound traffic except necessary protocols is the single highest-impact hardening step.

4. OPC-UA certificate management is critical but often neglected. The default self-signed certificates expire and are not trusted by clients. Implementing proper certificate lifecycle management significantly reduces man-in-the-middle risk.

5. CRA 2027 compliance is impossible without migration. The EU Cyber Resilience Act (effective January 2027) requires active vulnerability management and SBOM disclosure — neither of which a CP1584 can provide. Migration to AR 6.x hardware or an alternative platform is the only compliance path.

6. PVI credential leak (CVE-2026-0936) is the most immediately exploitable vulnerability. PVI logs usernames and passwords in plaintext on any PC running Automation Studio or PVI-based tools, creating a credential harvesting vector.

7. SA2025P003 SDM CVEs are the most dangerous unpatched SDM vulnerabilities. CVE-2025-3449 (session identifier prediction), CVE-2025-3448 (reflected XSS), and CVE-2025-11498 (CSV formula injection) all remain open on AR 4.x. CISA republished the advisory in May 2026 (ICSA-26-155-03 companion). CSV injection is particularly insidious — exported diagnostic CSV files can execute formulas when opened in Excel, potentially compromising the engineer’s workstation.

8. PPT30 OPC-UA DoS (CVE-2025-11482) affects HMI panels paired with CP1584 systems. CVSS v4.0 8.7 — an unauthenticated attacker can permanently crash the OPC-UA server on PPT30 panels by sending malformed concurrent connection requests, requiring a reboot. If your CP1584 uses a PPT30 HMI panel with OPC-UA enabled, update to PPT30 OS 1.8.0 or firewall the OPC-UA port (4840/TCP).

Cross-References

• ar-rtos.md — Complete CVE table, AR OS internals, VxWorks base
• access-recovery.md — Credential recovery, access control layers
• network-architecture.md — Network topology, device discovery
• firmware.md — Firmware architecture, AR R4.93 update
• firmware-version-mgmt.md — Version identification, upgrade procedures
• diagnostics-sdm.md — SDM vulnerabilities and configuration
• ftp-web-interface.md — FTP and web server interface details
• opcua.md — OPC-UA server security, certificates, policies
• pvi-api.md — PVI API, CVE-2026-0936 credential leak
• hmi-integration.md — HMI/VNC security considerations
• grounding-emc.md — Physical security, grounding, EMC
• safe-io-diagnostics.md — Safety system incident response
• program-reverse-engineering.md — Detecting unauthorized program changes
• python-diagnostics.md — Python-based monitoring scripts
• remanufacturing.md — Migration to patchable hardware
• cf-card-boot.md — CF card backup and imaging procedures
• troubleshooting-index.md — Security-related troubleshooting scenarios