Are you investing in OMLEX, or CAPEX driven by fear?
There has been a lot of talk that extending the life of existing control systems is a bad idea. That you must upgrade because of cybersecurity.
Let’s be honest. It’s not about cybersecurity. It’s about CAPEX.
OMLEX means Operation and Maintenance Life Extension. Keeping proven systems running, under control, with full ownership and understanding.
You are told your system is obsolete, risky, and must be replaced. But what are you actually getting? New software, new vulnerabilities, new dependencies, and another upgrade cycle in a few years.
1. On IEC 62443 Certification - OEM Evergreen Story
OEM keeps pushing for upgrades ... is new better? Think again!
Even within modernization and refurbishment projects, including recent T3000 / Omnivise deployments, it is not evident that all the listed IEC 62443 certifications are fully met across the board.
This raises a fundamental question:
Are we using certification as a meaningful assurance mechanism — or as a filtering tool without fully understanding what risk it actually covers?
- Mapped IEC 62443 functional requirements into auditable operational controls
- Translated these into a plant-specific risk profile
- Or aligned them systematically with other frameworks such as ISO 27000
2. Moving from Compliance to Risk-Based Thinking
I believe we need to shift the discussion from:
→ “Do we have the certificate?”
to:
→ “Do we understand and control our risks?”
ISO 27000 provides a useful foundation here, particularly in how it defines risk treatment strategies, including:
- reducing risk
- accepting risk
- transferring risk
- and importantly, avoiding risk
The last point is often overlooked, but highly relevant for OT.
Avoiding risk means:
not allowing conditions under which the risk can occur
In practical terms for control systems, this translates directly into:
- isolation
- segmentation
- controlled exposure
This is not theoretical — it is a recognized and valid approach within the standard itself, and aligns with the direction we should be taking.
3. Architectural Approach vs Tool-Based Security
A large portion of the questions raised relate to technologies:
- SIEM
- NGFW
- Anti-malware
- vulnerability scanners
- etc.
These are valid in IT environments, but in OT we must be cautious.
Adding layers of tools often introduces:
- additional complexity
- new dependencies (patching, signatures, updates)
- new failure modes
- and in some cases, new attack surfaces
The alternative approach — which we have seen in practice — is to focus on architecture first:
- strict separation of control systems
- elimination of unnecessary connectivity
- unidirectional data transfer where required (data diode concept)
- controlled and auditable interfaces only
In simple terms:
If the system is not reachable, it is significantly harder to compromise.
4. On Virtualization and Residual Risk
The concern regarding virtualization is understood, especially based on previous experiences.
However, the key difference in the approach being proposed is:
- virtualization is used as a preservation mechanism, not transformation
- control logic and automation layers remain untouched
- HMI environments are retained in a controlled and isolated context
- the overall system behavior remains deterministic
This is fundamentally different from full system upgrades, where:
- the entire platform changes
- new vulnerabilities are introduced
- and long-term dependency on OEM lifecycle increases
5. On Upgrades as a Cybersecurity Measure
We should also challenge one assumption:
Upgrading the system does not inherently improve cybersecurity.
In fact, experience across multiple plants shows that upgrades often:
- introduce new vulnerabilities
- create dependency on continuous patching cycles
- and lead to repeated obsolescence cycles
Even current platforms are bound by hardware lifecycle constraints:
- S7-300 is already discontinued
- spare parts availability is limited to defined timeframes
- costs increase while availability decreases
So the real question becomes:
Are we reducing risk — or simply shifting it while increasing cost and dependency?
6. Business Continuity as the Primary Objective
From a Gx perspective, our priority is clear:
Business Continuity.
Not compliance on paper, but:
- systems that continue operating
- systems that can be maintained and repaired
- systems that do not introduce unnecessary operational risk
This is where the concept of isolation-based cybersecurity becomes relevant:
- reduced attack surface
- predictable system behavior
- minimal external dependency
- controlled data flows
7. On OEM Interaction and Practical Reality
A concern was raised regarding OEM involvement.
The proposed approach does not interfere with:
- control logic
- engineering tools
- or automation layer operation
OEM support can still be engaged where required.
However, we should be realistic:
The biggest long-term risk is not lack of OEM involvement, but over-dependence on OEM-driven lifecycle and upgrade cycles.
8. Practical Way Forward
I suggest the following direction:
- Define an Company-specific OT cybersecurity model, based on:
- Focus on:
- Evaluate solutions based on:
—not only on certification status.
