Why cybersecurity should begin with the SCADA architecture

Last Updated 1 hour ago by Kenya Engineer

As industrial environments become more connected, cybersecurity is becoming an increasingly important consideration in how operational technology systems are selected, engineered and maintained. Remote access, enterprise integration, cloud connectivity and web-based interfaces have created significant opportunities for industrial organisations but have also changed the cybersecurity landscape.

For supervisory control and data acquisition (SCADA) systems in particular, the question is no longer simply whether appropriate security products have been installed around the automation environment. Organisations increasingly need to consider how security is incorporated into the underlying architecture itself.

Cybersecurity needs to be considered from the beginning of the automation lifecycle. The objective should be to make security part of the architecture and the way identities, access and communications are managed, rather than trying to add it once the system has already been engineered.

This reflects the broader direction of international cybersecurity guidance. CISA’s Secure by Design principles call for manufacturers to make security a fundamental product consideration, while NIST’s guidance for operational technology recognises that cybersecurity needs to be addressed alongside the particular safety, reliability and availability requirements of industrial systems.

Secure-by-Design

One of the clearest examples is the separation between the user-facing application and the server communicating with plant devices. Adroit’s security architecture is unique in that it adds another layer of separation and business logic between the clients and the control plane through the SmartUI Server.

Clients connect to SmartUI Server for access to graphics, project elements and authorised data, rather than connecting directly to the Agent Server that communicates with field devices. In a segmented deployment, the SmartUI Server can be placed in a demilitarised zone (DMZ), while the Agent Server remains within the lower-level OT environment at Purdue Level 2.

This separates presentation and interaction functions from the control layer. That middle tier provides a fundamental design advantage: client-facing access can be controlled at a separate application layer without making the device-facing server directly accessible to those clients. For organisations designing access around the Purdue model, this supports a layered approach to separating enterprise-facing services from operational systems.

More than authenticating a user

Adroit SCADA’s secure-by-design approach also builds on the Microsoft security framework on which its core server platform operates. This is significant because industrial cybersecurity involves more than logging a user into a SCADA application. Organisations need to establish who that user is, what systems and information the user may access, and what operational functions that identity should be permitted to perform.

Adroit SmartUI carries this identity through to execution. Authenticated requests execute in the logged-in user’s Windows security context, allowing native Windows security controls to enforce the permissions associated with that identity. The significance is that authentication is not disconnected from what the server subsequently does. User identity is preserved beyond login, supporting least-privilege enforcement and more meaningful auditing.

This is complemented by granular role-based authorisation down to individual data elements and user-interface controls, alongside support for enterprise identity technologies including Active Directory, LDAP and Microsoft Entra ID. For organisations already using this infrastructure, closer integration can help avoid creating an entirely separate island of OT identities and security administration.

Not mean Windows everywhere

An established server and identity environment also need not dictate the operating system on every user device. Adroit Secure Mobile Gateway provides HTML5 browser access to the Adroit Operator across supported Apple, Android, Linux and Windows devices. Authorised users can access it through a standard browser without installing endpoint agents, plugins or client software.

A browser, however, is a method of presenting an application. The cybersecurity question remains what services sit behind it, how users are authenticated and authorised, and whether accessing the application also creates a network path into OT. Adroit Secure Mobile Gateway’s Zero Trust Access capability is designed to provide authorised remote access without requiring inbound ports to be opened into the OT environment. The browser is not given direct network access to the SCADA server.

That is a different proposition from simply making a SCADA application available through a web interface. The aim is to make the required application functionality accessible without making the underlying operational network directly accessible to the remote endpoint. Access is provided through a separate sandboxed environment, with the remote display delivered as encrypted images rather than a direct browser connection to the control system. The product security documentation specifies TLS 1.3 encryption for these transfers.

Together, these measures are designed to reduce the exposure associated with remote access and limit opportunities for a compromised endpoint to reach the OT environment directly.  The gateway and the SmartUI middle tier address different parts of the architecture: one limits how remote users gain access; the other separates client-facing services from the device-facing server. Used within a properly segmented design, they provide complementary layers of protection.

Cybersecurity is also a lifecycle question

There is another consideration that receives less attention in discussions about SCADA cybersecurity: who will maintain the system five or ten years from now? Industrial automation systems generally have substantially longer operational lives than ordinary consumer or business applications. This means architecture decisions made during a project can have consequences long after commissioning.

No operating system eliminates the need for vulnerability management. The more useful question is whether the complete deployed environment can be inventoried, maintained, patched and supported throughout its intended operational life. Highly customised environments can become dependent on bespoke scripts, specialist packages, individual engineering knowledge or components that are difficult to reproduce several years later. That risk can arise on any operating system.

Open technologies and scripting can bring valuable flexibility. Organisations should nevertheless establish who owns those dependencies, how they are documented, how they will be updated, and whether another suitably qualified engineer could support the system if the original developer or integrator were no longer available. That consideration should form part of the cybersecurity discussion because lifecycle management, vulnerability management and support continuity are closely connected.

Making security easier to manage

Security still needs to be configured correctly. Networks still need to be segmented. Accounts and permissions need to be administered. Vulnerabilities need to be assessed and patches managed appropriately for the operational environment. What changes is the starting point. For Adroit, the architectural starting point brings together a separate SmartUI access tier, user-context permission enforcement and remote access designed to avoid direct exposure of the OT environment.

This means customers can build their security design around capabilities already present in the platform, rather than inventing the entire access model around the application after commissioning. Security is not simply something that has to be configured. It is something that should first be designed into the system and then managed throughout its operational life. For Adroit, this is enabled through its Secure-by-Design principles.