Mitsubishi Electric MELSEC and Omron Sysmac controllers run a large share of discrete manufacturing lines, especially in Asia, yet many sites still run them with open engineering ports, shared passwords and no logging. Both vendors now ship real access controls: user authentication with operation authority, IP and packet filters, encrypted engineering connections and security event history. They also both have a record of credential flaws, and Omron controllers were a named target of the PIPEDREAM (INCONTROLLER) toolkit. This guide explains how identity and access work on MELSEC iQ-R, iQ-F and MX controllers and on Omron NJ/NX and CS/CJ/CP controllers, which settings to turn on, how to log and detect misuse, and the misconfigurations that keep recurring. It assumes you know the basics in the PLC Security Guide and is written for OT engineers, controls integrators and OT security teams. Vendor function names are taken from vendor documentation; check the manual for your exact model and firmware, because support differs by series.
Key takeaways
- Turn on the authentication that exists. MELSEC MX controllers and Omron NJ/NX controllers support per-user authentication with operation authority; older MELSEC series rely on passwords and security keys that must be set deliberately.
- Firmware level decides your exposure. Omron fixed hard-coded credentials (CVE-2022-34151) and capture-replay (CVE-2022-33208) in NJ/NX firmware and Sysmac Studio releases from 2022; older firmware remains exploitable.
- Some modules will never be fixed. Mitsubishi states there are no plans to fix FTP password flaws in the RJ71EIP91 and FX5-ENET/IP EtherNet/IP modules and recommends replacement, so compensating controls and a replacement plan are required.
- The engineering workstation is the privileged path. GX Works and Sysmac Studio hosts, and the projects and passwords stored on them, are worth more to an attacker than any single controller.
- Logs exist but are rarely collected. MELSEC event history and Omron controller logs record logon failures, lockouts and filter blocks; without collection they are overwritten and lost.
How identity and access work in MELSEC and Omron controllers
Neither family was designed with directory-backed identity. Access control is local to the controller and the engineering project, and the protections available depend heavily on the series and firmware. Treat each protection as one layer, because the vendors themselves say the filters and passwords alone do not prevent all illegal access.
| Platform | Access protections (vendor names) | What they protect | Notes |
|---|---|---|---|
| MELSEC iQ-R | Security key authentication; file password; remote password; block password; IP filter | Execution, read and write of programs; file read and write on the CPU; Ethernet access routes; POU access; source IP allow-list | Mitsubishi FAQ 22481 describes each function; choose per purpose, they are not one combined login |
| MELSEC MX Controller (MX-R, MX-F) | User authentication (user groups, operation authority, lockout, password expiration); encrypted communication (TLS/DTLS with certificates); IP filter; default open port setting; bandwidth limitation; event history; encrypted backup | Who can connect and what they can do; confidentiality of engineering and external links; DoS resilience | Settings listed in Mitsubishi guideline BCN-P5999-1474-D V3.0 (April 2026) |
| Omron NJ/NX series | User authentication function; secure communication function; Packet Filter function | Per-user online operations limited by authority; encryption between Sysmac Studio or NA terminals and the controller; IP filtering on the built-in EtherNet/IP port | Setup is in section 8-5 of the NJ/NX CPU Unit Software User's Manual (Cat. No. W501) |
| Omron CS/CJ/CP series | Controller and program protection per the vendor's CS/CJ/CP CPU Unit Security Guideline (SBCA-148) | Program read protection and access restrictions | Older FINS-based designs; rely on network isolation and the vendor guideline for your model |
The protocols matter too. Omron engineering and data access commonly uses FINS (typically UDP port 9600), HTTP on NJ/NX for some functions, EtherNet/IP and OPC UA on newer controllers. MELSEC controllers use SLMP and the MC protocol, CC-Link IE networks, EtherNet/IP modules and, on MX controllers, encrypted engineering links. Legacy protocols such as FINS and plain SLMP carry no strong authentication, so anyone who can reach the port can often read or change data. See the Industrial Protocol Security Guide and the EtherNet/IP and CIP Security Guide.
Admin roles and privileged access
On these controllers, the privileged actions are program download and upload, online edits, operating mode changes, firmware updates, initialisation and changes to the security settings themselves. In ATT&CK for ICS terms these are T0843 Program Download, T0845 Program Upload, T0889 Modify Program, T0858 Change Operating Mode and T0836 Modify Parameter. Every one should require an individual, authenticated user where the platform allows it.
- Individual accounts: on MX and NJ/NX controllers, create a named account per engineer and integrator rather than one shared "admin". Mitsubishi recommends setting operation authority per user group with the minimum authority needed for user-defined groups.
- Read-only roles: give operators, maintenance staff and historians monitoring authority only. Reserve write, mode change and firmware rights for a small engineering group.
- Password policy: for MX controllers Mitsubishi recommends password expiration, password strength set to "Strong", an appropriate lockout count and lockout time, and session timers. Apply equivalent settings on NJ/NX user authentication.
- Legacy passwords and keys: on iQ-R, set security key authentication so only PCs holding the registered key can read, write or execute protected programs, and set remote passwords on Ethernet routes. Store the key files and passwords in the site vault, not in the project folder.
- Integrator access: give integrators time-bound accounts and remove them after commissioning. Contracted engineers are often the only people who know the passwords; fix that at handover. See the OT Third-Party and Integrator Access Guide.
- Remote access: route vendor and integrator connections through a brokered, recorded remote access service with MFA, as AA22-103A recommends, rather than direct VPN to the controller network. See the OT Remote Access Guide.
Integrations, tokens and service accounts
Controllers talk to HMIs, SCADA servers, historians, MES and vision systems, and those connections are machine identities. They often hold the most durable credentials on the network, because nobody wants to break a running line by changing them.
- HMI and SCADA links: Omron NA programmable terminals and third-party HMIs connect to NJ/NX controllers; Omron's 2022 advisory fixed NA5 runtime as well as the controllers, which shows the HMI side is in scope for credential flaws. Give each HMI its own account with the minimum authority.
- Module services: communication modules can expose FTP, HTTP or other services with their own credentials. Mitsubishi's advisory for RJ71EIP91 and FX5-ENET/IP describes weak and hard-coded FTP passwords and recommends disabling FTP except during configuration, using the Connection Permission Change function (firmware 06 or later) or the Tool connection setting change function (firmware 1.106 or later).
- Certificates: MX controllers use certificates for TLS/DTLS; Mitsubishi recommends keeping the default one-year certificate expiry. Track expiry dates in your certificate inventory so renewals do not cause an outage that tempts staff to turn encryption off.
- OPC UA and gateways: where an OPC UA server or protocol gateway sits in front of the controllers, its user accounts and application certificates are the identity boundary. See the OPC UA Security Guide.
- Stored secrets: engineering projects, HMI projects and backup files can contain passwords. Encrypt backups (MX controllers support optional backup encryption) and restrict who can open project archives.
For the identity model across the plant, see the OT and ICS Identity and Access Guide.
Lessons from PIPEDREAM and vendor advisories
CISA advisory AA22-103A described a toolkit with modules for Omron Sysmac NJ and NX controllers, naming the NX1P2, NX-SL3300, NX-ECC203, NJ501-1300, S8VK and R88D-1SN10F-ECT and noting the list may not be complete. The Omron module could scan for devices using FINS, parse HTTP responses, back up and restore files, and load an agent that accepted commands over HTTP or HTTPS. The advisory mapped these behaviours to techniques including Remote Services (T0886), Valid Accounts (T0859), Network Sniffing (T0842), Program Upload and Download, Service Stop (T0881) and Modify Parameter. Later in 2022, Dragos reported that a component it called BadOmen exploited CVE-2022-34151 to interact with the HTTP server on NJ/NX controllers, as reported by SecurityWeek. ATT&CK v20 now places default and hard-coded credentials under T1694 Insecure Credentials (T1694.001 and T1694.002). See the PIPEDREAM (INCONTROLLER) ICS Toolkit Guide.
| Advisory | Products | Issue | Fix or compensating control |
|---|---|---|---|
| Omron OMSR-2022-001 (CVE-2022-34151, CVSS 9.4; CVE-2022-33208, CVSS 7.5) | NX7 1.28 or lower; NX1 and NJ 1.48 or lower; Sysmac Studio 1.49 or lower; NA5 runtime 1.15 or lower | Hard-coded credentials; authentication bypass by capture-replay | Update to NX7 1.29, NX1 1.50, NJ501-1300/1400/1500 1.49 or other NJ 1.50, Sysmac Studio 1.50, NA5 1.16 or later; enable secure communication, Packet Filter and user authentication |
| Mitsubishi 2023-004 (CVE-2023-2060 to 2063) | RJ71EIP91 and FX5-ENET/IP (all versions); configuration tools 1.01B and prior | Weak and hard-coded FTP passwords; unmasked password display; unrestricted file upload | No fix planned for the modules: replace with RJ71GN11-EIP or FX5-EIP; disable FTP outside configuration; IP filter; update tools to 1.02C |
| CISA AA22-103A | Omron NJ/NX listed models | Toolkit abusing native functions and credentials | Isolate, allow-list engineering workstations, unique passwords, offline backups, hash firmware and configuration, OT monitoring |
For how to triage the steady stream of advisories for these vendors, see the ICS Advisory Triage and OT Vulnerability Management Guide. Mitsubishi Electric has been a CVE Numbering Authority since December 2020, and both vendors publish advisories through their own PSIRT pages, so subscribe there as well as to CISA ICS advisories.
Logging and detection
MELSEC MX controllers keep a security event history. Mitsubishi recommends storing it in data memory rather than an SD card, backing it up regularly to a PC because the oldest entries are overwritten, setting accurate time, and enabling the manipulation check. The events it says to watch are logon failures and lockouts, unusual file access or read/write patterns, access attempts from addresses blocked by the IP filter, and deletion of event history.
- Controller events: collect logon failures, lockouts, mode changes, program downloads, firmware updates and security setting changes from the controller logs on a schedule, and forward them to the OT SIEM.
- Network monitoring: passive OT monitoring should decode FINS, SLMP, EtherNet/IP and OPC UA and alert on program transfers, mode changes and new talkers. AA22-103A suggests CISA's open-source ICSNPP parsers for Zeek. See the OT Network Security Monitoring Guide.
- Integrity checks: hash controller programs, configuration and firmware and compare against a known-good baseline after every planned change, as AA22-103A recommends.
- Engineering workstation telemetry: monitor GX Works and Sysmac Studio hosts for new drivers, unusual tools and connections to controllers outside change windows. AA22-103A recommends Credential Guard, HVCI and EDR on management systems.
- Symptoms: treat communication delays, unexpected reboots and slow responses to operator commands as possible indicators, not just maintenance issues.
Metrics that show progress:
- Percentage of controllers with per-user authentication or security key and remote password protection enabled.
- Percentage of NJ/NX controllers and Sysmac Studio installs at or above the fixed versions in OMSR-2022-001.
- Number of unfixable modules (such as RJ71EIP91) still in service, with replacement dates.
- Percentage of program downloads matched to an approved change record.
- Days of controller event history retained off the device.
Hardening baseline
Use this order of work. Test every change on a spare controller or during a planned outage, record the previous settings, and keep a known-good offline backup so you can roll back.
- Inventory: list every MELSEC and Omron CPU and communication module with series, firmware, network ports and which workstations may connect.
- Isolate: place controllers in a cell zone behind a firewall, allow only named engineering workstations and HMIs, and block FINS, SLMP, FTP and HTTP from all other zones. Mitsubishi's guideline asks that SNTP, FTP, Modbus/TCP, HTTP and CC-Link IE TSN traffic stay inside the trust boundary and that remote PCs outside it are allowed only on encrypted ports. See the OT Network Segmentation, Purdue Model and IEC 62443 Zones and Conduits Guide.
- Turn on controller filters: configure the MELSEC IP filter and the Omron Packet Filter to the same allow-list, and close unused default ports on MX controllers.
- Enable authentication: user authentication on MX and NJ/NX controllers, security key authentication and remote passwords on iQ-R, and unique strong passwords everywhere.
- Encrypt engineering links: use the Omron secure communication function and MX encrypted communication for any connection that crosses a trust boundary.
- Patch or replace: bring NJ/NX and Sysmac Studio to fixed versions; plan replacement of modules with no fix; disable FTP on modules where it is only needed for configuration.
- Back up and verify: take encrypted offline backups of programs and settings, hash them, and review all settings at least yearly, as Mitsubishi recommends.
Decision guidance
- Legacy series without user authentication: rely on security keys, passwords, IP filtering and strict zoning, and put the controller on the replacement roadmap.
- Patch now or wait for an outage: for an internet-reachable or flat-network controller with a critical credential flaw, schedule an urgent outage; for a well-zoned controller, apply compensating controls and patch at the next planned stop.
- Small sites: start with zoning, unique passwords and offline backups, which give most of the risk reduction for little cost. Large sites should centralise logs and integrity checks across lines.
Framework mapping
| Framework | Reference | Applies to |
|---|---|---|
| NIST SP 800-53 Rev. 5 | IA-2, AC-6 | Individual controller accounts; least-privilege operation authority |
| NIST SP 800-53 Rev. 5 | SC-7, CM-7, AC-17 | Zoning and IP filters; closing unused services such as FTP; brokered remote access |
| NIST SP 800-53 Rev. 5 | CM-3, SI-7, CP-9 | Change control for downloads; firmware and program integrity; offline backups |
| NIST CSF 2.0 | PR.IR-01, PR.PS-01, DE.CM-01 | Protect controller networks, configuration management, network monitoring |
| MITRE ATT&CK for ICS v20 | T0843, T0845, T0859, T0886, T1694 | Techniques the controls above are meant to block or detect |
| IEC 62443 | Product and system security | Both vendors state IEC 62443-4-1 development certification for parts of their FA business; see the IEC 62443 Guide |
Common misconfigurations
- Security functions never enabled: controllers ship with protections available but off, and integrators leave them off to simplify commissioning.
- One shared engineering password: every engineer and contractor uses the same password, which never changes and appears in project notes.
- Old NJ/NX firmware: controllers below the OMSR-2022-001 fixed versions still accept the hard-coded credentials that PIPEDREAM-era tooling used.
- FTP left on in communication modules: modules with weak or hard-coded FTP passwords keep the service open permanently.
- Flat networks: FINS and SLMP reachable from the office network or a vendor VPN, so any compromised laptop can talk to the controllers.
- Logs overwritten: event history fills and rolls over before anyone looks at it, so an incident leaves no trace.
Practitioner checklist
- Inventory every MELSEC and Omron CPU and module with firmware and open services.
- Zone controllers and allow only named engineering workstations and HMIs; mirror the allow-list in the IP filter or Packet Filter.
- Enable per-user authentication with least operation authority on MX and NJ/NX; security key and remote password on iQ-R.
- Bring NJ/NX controllers, NA5 terminals and Sysmac Studio to the fixed versions in OMSR-2022-001.
- Disable FTP on RJ71EIP91 and FX5-ENET/IP outside configuration and schedule their replacement.
- Encrypt engineering links that cross a trust boundary and track certificate expiry.
- Collect controller event history off the device and alert on lockouts, filter blocks and log deletion.
- Hash programs and firmware, keep encrypted offline backups and review settings at least yearly.
- Harden and monitor GX Works and Sysmac Studio workstations as privileged systems.
Standards and references
- Mitsubishi Electric: FA System Security Guideline, Separate Volume [MELSEC]
- Mitsubishi Electric: Security functions of MELSEC iQ-R series (FAQ 22481)
- Mitsubishi Electric: Multiple vulnerabilities in MELSEC iQ-R and iQ-F EtherNet/IP modules (2023-004)
- OMRON: Authentication bypass vulnerabilities in NJ/NX-series controllers (OMSR-2022-001)
- CISA: APT Cyber Tools Targeting ICS/SCADA Devices (AA22-103A)
- MITRE ATT&CK: Insecure Credentials (ICS)
- Mitsubishi Electric: PSIRT
- SecurityWeek: Omron PLC vulnerability exploited by sophisticated ICS malware
Related NHI Mgmt Group resources: PLC Security Guide · PIPEDREAM (INCONTROLLER) ICS Toolkit Guide · Engineering Workstation Security Guide · OT Patch Management Guide