Regarding the security of cMT Viewer, questions often arise, especially when it is installed on PCs within the IT network. From an architectural point of view, I would like to confirm a few points: Does cMT Viewer only mirror/render the HMI interface, or does it execute any instance of the project (scripts, macros, or logic) locally on the PC? When the HMI project uses macros, JavaScript, or events, does all execution remain exclusively on the HMI, even when user interaction occurs via cMT Viewer? In the case of web requests (HTTP/HTTPS, REST, MQTT, etc.) triggered by JavaScript or native HMI functions, are these communications always originated by the HMI itself, or is there any scenario in which the PC running the Viewer participates in the execution or the network stack? From an attack surface perspective, should cMT Viewer be treated only as a remote viewing client, or are there any additional considerations in terms of code execution or access to the industrial network? The idea is to clarify whether the cMT Viewer can be evaluated, in terms of security, similarly to a remote access client for the interface, keeping all logic and communication concentrated in the HMI.
Hi @eddy_neves ,
Thank you for your questions.
The cMT Viewer runs a separate instance of the HMI project and transfers only project data from the HMI to the PC. In certain cases, some execution, such as JavaScript-based requests, may occur on the PC when triggered by user actions. However, scripting such as macros run exclusively on the local HMI.
To ensure that communication and execution remain restricted to authorized HMI users, we recommend protecting command execution using Combo Buttons or objects that support Control Tokens. This will ensure that execution is restricted to users on the HMI and not invoked through cMT viewer which can lead to PC execution.
So, from an architectural point of view, the cMT Viewer should be treated not just as a view client, but as a partial runtime endpoint, where part of the project (especially JavaScript-based actions) can be executed on the PC when triggered by user interactions. In this context, the recommendation to use objects with control tokens or combo buttons makes perfect sense, to ensure that certain critical actions are restricted to the physical HMI. This helps to correctly frame the cMT Viewer within corporate IT policies, not as an industrial logic executor, but as an authorized endpoint that requires proper governance.
Hi @eddy_neves ,
Yes, cMT Viewer is not solely a view client, as it can execute certain actions such as specific programs or requests on the PC rather than directly on the HMI. From a security perspective, cMT Viewer should therefore be protected according to the project’s requirements, as you mentioned.
Additionally, access can be further controlled by limiting the number of concurrent cMT Viewer connections through the system parameters.
Thank you!
