Designing HMI/SCADA applications with cybersecurity in mind: principles that reduce risk already at the design stage

The security of an HMI/SCADA application is determined much earlier than at the stage of selecting protection mechanisms. Whether the system can withstand error, misuse, and uncontrolled process state changes depends primarily on the assumptions built into the design: role separation, trust boundaries, the range of functions available through the interface, and the way service and remote access are organized. If these issues are treated as secondary, the application will start embedding risk instead of reducing it. That is why designing HMI/SCADA with cybersecurity in mind must be treated as an engineering task: first determine which operations are critical, what their consequences may be, and who should actually be allowed to perform them, and only then build screens, alarms, and operator conveniences.

Cybersecurity starts in the design

In HMI/SCADA systems, cybersecurity is not an add-on applied to a finished visualization. It stems from decisions made earlier: the application architecture, the permissions model, the way the control system is connected, and the assumptions for service access. This is particularly important because an HMI/SCADA application is the point where people, process, and infrastructure meet. A design flaw therefore does not end with IT risk. It can also affect operator response, functional safety, operational risk, and production continuity at the same time.

From a design perspective, the key question is not what safeguard to add at the end, but which decisions made at the outset will reduce the attack surface. The biggest problems usually do not come from the absence of a single mechanism, but from excessive trust built into the application. In practice, this means shared user accounts, broad and permanent service access, no separation of roles between the operator, maintenance, and the integrator, and overly permissive communication between the operator layer and the control system. At the commissioning stage, such solutions seem convenient because they speed up work and make diagnostics easier. Later, they become a permanent feature of the environment and increase the risk of misuse, error, or uncontrolled changes to the process state.

That is why, before designing screens, it is worth defining not only what the user should see, but above all where the trust boundaries lie, which operations are critical, and where the interface may become a tool for error or a way around procedure. This sequence brings order to later decisions: whether the HMI is to be only a visualization layer or also a place for configuration, diagnostics, and recipe changes; whether service functions are to remain active permanently or only after deliberate activation; whether the operator is to have access only to process operation or also to functions that change parameters and data history.

The practical cost of neglect usually becomes visible only when the application is already tied to recipes, alarms, reporting, archiving, and maintenance procedures. At that point, even an apparently simple correction, such as separating accounts, changing the approval path for a critical operation, or limiting remote access to occasional use, stops being just a screen change. It requires reworking the logic, retesting alarm handling, defining responsibilities, and often organizational changes at the plant as well.

In practice, the most sensible starting point is a working map of user roles and their permissions for critical operations, a list of functions that can change the process state, configuration, or recipes, and a register of external connections covering service, reporting, higher-level systems, and remote access. Only on that basis does it make sense to design the architecture of zones and connections and prepare the later risk assessment. This approach aligns both with engineering practice and with the need to structure responsibilities, separate functions, and control communications in industrial automation environments.

Where cost and risk really increase

The greatest cost and risk in an HMI/SCADA application do not result solely from the fact that systems are connected, but from the process and organizational consequences triggered by specific application functions. The most sensitive points are those that allow settings to be changed quickly, a bypass to be introduced, an alarm to be silenced, a recipe to be changed, or manual control to be performed without full process context. If the design allows such operations from the production screen as a routine matter, the risk increases because a single user decision or a single compromised session can directly change the state of the process.

This means the catalogue of critical operations must be treated as part of the safety architecture, not merely as an interface ergonomics issue. The same applies to accountability. Shared logins, shift-shared accounts, no separation between read, control, configuration, and administration privileges, and poor event logging make it difficult after an incident to determine reliably whether it resulted from a mistake, a procedural workaround, misuse of service access, or unauthorized action. The issue goes beyond root-cause investigation alone. Without a reliable record of user actions, it is also impossible to assess how effective procedures are, manage permissions sensibly, or defend operational decisions during an internal audit, against customer requirements, or under adopted security policies. In practice, this is about accountability and traceability, not just event recording itself.

Another very costly design mistake is carrying extensive service and diagnostic screens into the production environment when they were originally created for commissioning or integrator support. Such views often provide broad access to internal variables, state forcing, interlock clearing, and parameter changes, even though under normal operation they are needed only occasionally at most. If they are not subject to additional restrictions, they become the shortest path to interfering with the process outside the normal operator workflow. A sensible approach is to separate diagnostics needed by maintenance from functions that allow intervention in the operating logic, and to decide separately whether the machine manufacturer’s diagnostics should be available locally, remotely, or only conditionally, after deliberate activation and with full session recording.

The same approach should be taken to integration with databases, reporting, remote support, and office systems. Every such connection improves convenience, but at the same time increases the number of dependencies that can become an entry path, a source of disruption, or a cause of blurred responsibility. Failure of an intermediary service, incorrect time synchronization, uncontrolled data exchange with a higher-level system, or a service channel left open may affect not only report availability, but also decisions made by the operator.

That is why, already at the design stage, it is worth measuring not only screen availability, but also simpler and more useful indicators: the number of critical operations possible from the production HMI, the number of active external connections, the number of privileged accounts, and the scope of events covered by the audit trail. This kind of review later brings order to event logging, parameter change control, and remote access rules.

Alarm handling requires separate treatment. In this area, apparent completeness often masks a real lack of control. Poorly designed alarms and event history not only overload the operator, but also remove the ability to distinguish critical signals from technical noise. If an alarm can be easily silenced without justification, acknowledged without reference to the cause, or lost in a mass of diagnostic messages, the application stops supporting process safety. That is why alarm priorities should follow the actual impact on people, the machine, and production quality, and remain linked to the rules for recording acknowledgements, overrides, and setpoint changes. This is exactly the point at which risk analysis stops being a formal document and starts shaping the interface.

How to design to limit the effects of error and misuse

The starting point is simple: an HMI/SCADA application cannot assume that every user always acts correctly and in the right process context. The design should begin with function separation, not with drawing screens. The team should first determine what the operator is only allowed to see, what they may acknowledge, what they are allowed to change in the normal course of work, and which actions must be moved to service mode, covered by additional authorization, or completely separated into a dedicated tool or station.

That decision brings order to the entire access architecture: roles, permission scope, how actions are recorded, and the conditions for remote support. In practice, a role matrix based on actual responsibilities works well, distinguishing the operator, shift leader, maintenance, process engineer, integrator, and administrator. This is not a formality. If service functions remain on the same screen and under the same account as process operation, the application itself creates a path to error, procedural bypass, or privilege misuse.

Good HMI/SCADA design in industrial automation environments limits the possibility of performing a dangerous operation by accident, but does not unnecessarily slow down routine tasks. This requires a clear operating context: the user should see which asset they are working on, what state the process is in, whether they are acting locally or remotely, and whether the system is in automatic, manual, or service mode. Confirmations must be proportionate to the risk, not identical for all actions. Where the effect of an error is reversible and limited, a single authorization is usually enough. Critical operations require additional control: a second confirmation, re-authentication, dependence on process state, or physically moving to a segregated interface.

Conditional interlocks are also important. If the application allows a setpoint change, signal forcing, or switching to manual mode regardless of the equipment state, the risk is shifted from the design to the operator. This is exactly where it becomes clear that proper interface design is not just about ease of use, but about limiting the consequences of error through built-in barriers. In many cases, this way of thinking is close to how Poka-Yoke works on production lines.

Layered access design should also cover how permissions are used over time. Individual accounts are essential wherever action traceability is required. A shared account removes the ability to determine who actually made a decision. Least privilege means that a user gets only the functions needed for current work, while elevated permissions are granted temporarily and under controlled conditions. This applies in particular to maintenance, the integrator, and the manufacturer’s remote support. A permanently open service path is only superficially convenient, because it removes the natural trust boundary between operations and service. A safer model is access enabled on request, limited in time, assigned to a specific person, and recorded in the event history. This approach aligns well with the principle of least privilege and access segmentation, and with safety by design.

In the same spirit, it must be decided whether service functions should be available from the working HMI or only from a separate station, and whether removable media and local data import or export should be allowed from the operator panel. These decisions are not secondary. They determine whether system maintainability will be handled in a controlled way or through ad hoc workarounds.

From the perspective of an incident or an operational dispute, the interface alone is not enough. The application must leave evidence that makes it possible to reconstruct the decision path. Event history, system logs, and change recording should together answer not only what happened, but also who performed the operation, when, from where, and in what process state. The minimum scope of events that is usually worth recording includes login, permission changes, parameter changes, switching to manual mode, alarm acknowledgement, and configuration import. Linking the record to the process context is critical, because information about a change alone, without the equipment state, may be useless.

A good example typical of many implementations is changing an alarm threshold by a process engineer. This may be allowed, but only after entering the intended mode, with the user, station, time, previous and new value recorded, and confirmation that the equipment was not in a critical state. Such a record matters both for safety and for change management in industrial applications.

The final layer is maintainability without bypassing safeguards. If an update, configuration restore, or diagnostics requires disabling access control, using a shared password, or working without an audit trail, the problem lies in the design, not in staff discipline. The application should have a defined change workflow: request, impact assessment, test, implementation, confirmation, and rollback plan. It should also separate the operational and service environments at least logically and, where justified, also organizationally and technically. Configuration backups must be possible to create and restore in a controlled way, without ad hoc export “just in case” from the panel. This approach is consistent with the principle of least privilege in OT and with requirements for access control, action traceability, and change management, although their scope must always be related to the system architecture and the adopted division of responsibilities.

Implementation practice and reference to requirements

The greatest benefit comes not from adding more protection mechanisms at the end of a project, but from a structured application review before acceptance or modernization. This is the point at which the system’s operating model can still be corrected at relatively low cost, instead of later surrounding flawed assumptions with additional procedures. Such a review should be carried out by a mixed team: design, maintenance, operations, automation, and the people responsible for safety.

The subject of the assessment is not only the technical configuration, but whether the application actually separates roles, protects critical operations, limits remote access to justified cases, provides clear alarm handling, preserves change history, and allows backups and emergency procedures to be performed without bypassing safeguards. It is precisely this review that should produce the list for FAT/SAT and the requirements entered into acceptance, the service plan, and the as-built documentation.

This approach shifts the focus away from discussing safeguards alone and toward design decisions that later determine how people and equipment behave. If, at the design stage, it has not been defined who may change recipe parameters, who approves service mode, how integrator intervention is recorded, and under what conditions off-site access is allowed, then once the system goes live it will rely on exceptions and informal verbal arrangements.

For the same reason, it is worth deciding whether the application assessment should be carried out as part of a machine or line upgrade, or as a separate OT review. The first approach ties security more closely to the process function; the second makes it easier to identify dependencies between systems and to allocate responsibility for accounts, permissions, and activity logging. This is also the natural point for a preliminary risk analysis: identifying critical operations, trust boundaries, and the consequences of operator error or misuse. In practice, project risk analysis can also be helpful here, especially during the design and engineering stage.

• user roles and login methods,
• critical operations and the rules for confirming them,
• remote access and service functions,
• alarms, change logging, and accountability for actions,
• backups, recovery, and emergency procedures.

Good results in a plant rarely come from deploying many tools at once. Usually, it matters more to eliminate a few systemic risks that have been treated as practical for years. Upgrading an HMI/SCADA application may begin with removing shared accounts, separating service functions from operator functions, limiting external connections to controlled paths, and enabling a parameter change trail assigned to a specific person or role. Such a change does not have to make life harder for maintenance or the integrator, provided that service mode, authorization rules, and a repeatable modification workflow were built in from the outset.

During operation, it is then worth measuring not an abstract level of security, but operationally useful indicators: the number of shared accounts still present in the system, the scope of active remote access, the completeness of change logs, configuration recovery time, and the number of interventions performed outside the formal procedure. These metrics make it possible to assess whether the project actually reduced risk or merely shifted it into day-to-day practice.

In the Polish and EU context, it is becoming increasingly difficult to defend an approach in which HMI/SCADA cybersecurity is treated as the sole responsibility of the IT department. Responsibility is spread across design, operations, maintenance, suppliers, and integrators, and industry and contractual requirements matter only when the organization can show specifics: what design decisions were made, how permissions are assigned, what action trail exists, and who controls changes. References to standards, policies, or contract clauses alone are no substitute for evidence that the application was designed and accepted in a way that enables safe operation. In many cases, this kind of verification is supported by a broader production safety audit.

The key conclusion is practical. The cheapest and most effective point for reducing risk remains the design and acceptance stage of the application. That is when trust boundaries, roles, access conditions, action trails, and the change process can be defined at the lowest cost. If these requirements are translated into verifiable criteria for the supplier and integrator, HMI/SCADA stops being a convenient but overly trusting interface and becomes a tool for safe process operation.