SCADA Modernisation Best Practices & Lessons Learnt
Every SCADA modernisation project involves substantial modifications to a critical infrastructure system. While engineering and delivery teams are mainly focused on the system upgrade, meeting deadlines and managing vendors, cybersecurity can sometimes receive less attention during the transition.
This is not a criticism of the teams involved. From our experience supporting SCADA modernisation projects, we have seen that this is often a structural challenge. Projects are usually designed to get the new SCADA system up and running safely and on time, rather than to maintain or improve the existing security posture.
As a result, a common risk can emerge: the old SCADA system may have known security weaknesses, but the transition to the new upgraded system may introduce new and less visible risks.
Ready to assess your SCADA modernisation readiness? Go straight to the SCADA Modernisation Readiness Checklist → and identify potential risks across architecture, segmentation, vendor access, and cybersecurity controls.
Need more context? The guide below breaks down the common gaps, risks, and practical actions to improve your readiness.
The Key Cybersecurity Risks During SCADA Modernisation Projects
Modernisation risk clusters around predictable failure points, almost all of which are more about process than technology.
Segmentation erodes during commissioning – and doesn’t fully come back. Temporary flat-network configurations, “just for testing” firewall rules, and direct connections used to speed up commissioning have a habit of outliving the commissioning phase. Nobody removes them on purpose; they just never get prioritised for cleanup once the new system is running.
Vendor and integrator access outlives the project. Modernisation brings more third parties into the OT environment than steady-state operations ever do – commissioning engineers, integrators, OEM support staff. Access granted for a six-week cutover frequently has no defined expiry, no review point, and no owner responsible for revoking it once the work is done.
New architecture increases attack surface by default. Migrating from legacy serial or proprietary fieldbus protocols to Ethernet based communications is usually the right long-term decision – and it also means components that were previously unreachable from a network perspective become reachable, unless the migration is designed with that consequence in mind from the outset.
Regulatory continuity gets treated as a formality. CIRMP updates, board notification of material changes to a registered asset, and reassessment of Systems of National Significance status often happen after go-live, as a paperwork step – rather than being designed into the program alongside the technical cutover.
None of these are exotic risks. They’re what happens when a legitimate, necessary engineering program runs without a security lens built into its own project plan.
SCADA Upgrades: Best Practices & Lessons Learned
Through our work supporting OT modernisation programs, we have consistently seen that organisations achieve stronger outcomes when cybersecurity is embedded into the SCADA upgrade lifecycle rather than treated as a separate project.
Design the architecture before you select the hardware. Segmentation, zoning, and network boundaries should be decided as part of the target architecture – ideally aligned to a recognised model such as IEC 62443 zones and conduits – before vendor and component selection locks in constraints that are expensive to unwind later. On our salt and gypsum SCADA system integration, this discipline started with an enterprise architecture defining the final-state operating environment before any procurement or migration work began – which is what allowed the team to rebuild SCADA & historian systems on new infrastructure without re-architecting mid-project.
Furthermore, the current SCADA upgrade project at Onslow Salt provides another example of advanced automation engineering. The project involves transitioning the SCADA platform from Wonderware InTouch to Ignition, creating a more modern, resilient and operator-focused control environment. By combining modern SCADA architecture with high-performance HMI principles, the upgrade is designed to improve system reliability, performance and operational visibility across the Wash Plant.
Build the fallback plan before you need it. A documented rollback path for a modernised component that fails in production is cheap to write in advance and expensive to improvise under pressure during a live cutover. We have experienced it firsthand in the SCADA integration project above, where the previous owner had removed all IP, servers, and computing infrastructure, leaving only backups. With no fallback beyond those backups and a four-hour cutover window, rigorous off-site testing and FAT simulation before the switchover – not during it – was the only thing standing between the team and unplanned downtime.
Treat vendor access as a managed control, not a courtesy. Time-bound access, logged sessions, and a defined offboarding step should be as much a part of the commissioning plan as the cutover schedule itself – with a named owner accountable for revoking access when the work finishes. Our solar farm control system project made this non-negotiable: with multiple subcontractor systems from different suppliers and limited interface definitions between them, undocumented or lingering vendor access into any one sub-system would have put the whole integration at risk.
Run regulatory continuity in parallel with engineering, not after it. CIRMP updates, board reporting on material asset changes, and reassessment of enhanced obligations should track the program’s milestones – design, commissioning, cutover – rather than becoming a closeout task once the new system is already running. On a first-of-its-kind renewable integration like the solar farm project, sustained attention to cyber security and long-term hardware obsolescence risk was called out by the client as a defining feature of the engagement, not an afterthought bolted on once the system was live.
Protect the security testing milestone from schedule pressure. A cyber security assessment of new SCADA components before go-live is one of the few checks that cannot be recovered after the fact – it has to happen before production, or it doesn’t happen at all.
A Practical SCADA Modernisation Cybersecurity Checklist
In practice, this means running SCADA modernisation as a program with security decision points built into the same plan as the engineering milestones:
1. Architecture review at design, not deployment. Validate segmentation, zoning, and remote access design before procurement locks in the constraints.
2. A managed vendor access model for the life of the project. Time-bound, logged, MFA-protected access through a bastion – provisioned and de-provisioned as a defined process, not an informal favour.
3. Staged testing with a real fallback. Components proven in a staging or replica environment, with a documented rollback path, before they touch production.
4. Regulatory continuity as a program milestone. CIRMP updates, board notification, and SoNS reassessment tracked alongside the technical cutover – not queued up behind it.
This is the model Tier Sixteen applies to OT modernisation programs generally: security decisions embedded in the same plan as the engineering ones, so the SCADA system upgrade closes risk instead of quietly relocating it.
How exposed is your modernisation program right now?
We designed a 16-point SCADA modernisation Readiness Check that scores your program legacy risk baselining, architecture and segmentation, vendor access, change management, and regulatory continuity.
This checklist is designed for asset owners, operators, engineering teams, cybersecurity leaders, and project managers responsible for registered