For years, industrial cybersecurity was primarily discussed in terms of network protection: firewalls, segmentation, VPNs and secure remote access. These remain essential, but the conversation is changing.
As industrial products become increasingly connected, software-driven and remotely maintainable, cybersecurity can no longer stop at the network boundary. It must extend to how products are designed, developed, updated and supported throughout their operational life.
In 2026, this transition is becoming particularly visible. European regulatory requirements are moving into implementation, cybersecurity standards are influencing product engineering more deeply, and manufacturers are being asked to take greater responsibility for what happens to products after they enter the market.
For machine builders and industrial technology providers, the question is therefore evolving from “How do we protect a connected machine?” to “How do we maintain its cyber resilience over time?”
Regulation is moving from theory to operation
The European regulatory landscape provides one of the clearest signals of this change. The Cyber Resilience Act (CRA) introduces mandatory cybersecurity requirements for products with digital elements, addressing cybersecurity across planning, design, development and maintenance.
Most CRA obligations will apply from December 2027, but an important milestone arrives earlier: from 11 September 2026, reporting obligations concerning actively exploited vulnerabilities and severe incidents start to apply. The framework includes an early warning within 24 hours and further notification within 72 hours.
The significance goes beyond reporting. The CRA reinforces a fundamental change in perspective: a product cannot simply be considered secure when it leaves development or is installed on a machine. Vulnerabilities can emerge later, software dependencies evolve, threats change and deployed products may require security updates.
Security therefore becomes a lifecycle responsibility.
The connected machine has changed the security perimeter
There is another reason why this shift is happening: industrial architectures themselves have changed.
HMIs, industrial PCs, gateways and controllers increasingly communicate with enterprise systems, remote services, cloud platforms and other machines. Software can be updated remotely, operational data can travel beyond the machine, and applications increasingly rely on interconnected software components.
The traditional distinction between an isolated OT environment and external IT infrastructure is therefore becoming less clear. This does not make VPNs, firewalls, secure remote access or network segmentation less important. Quite the opposite: they remain fundamental components of industrial cybersecurity.
But protecting connectivity is only one part of protecting the product. A secure connection does not automatically mean that the software behind it has been securely developed, that vulnerabilities are systematically managed, that an update can be trusted or that the product can remain securely supportable throughout its expected lifetime.
Cybersecurity consequently moves deeper into product engineering.
From protection to secure development
This is where standards such as IEC 62443 become particularly relevant. One of their key principles is that security cannot depend exclusively on the final characteristics of a product; the processes used to design, develop and maintain that product matter as well.
IEC 62443-4-1 addresses the secure product development lifecycle, bringing cybersecurity into engineering practices through areas such as security requirements, secure design, verification, vulnerability management and security updates. IEC 62443-4-2, by contrast, addresses technical security requirements at component level.
The distinction illustrates something broader than certification itself. Cybersecurity is not simply a certificate to obtain or a collection of security features to add to a product. It is a continuous engineering discipline involving both processes and products.
Vulnerability management becomes part of product management
This also changes the relationship between manufacturers and products already operating in the field.
Traditionally, industrial product development could largely be viewed around release milestones: develop, validate, manufacture, deploy and support. Connected products require a more continuous relationship.
A vulnerability discovered years after deployment may still need to be assessed. Software components and dependencies must be understood. Security updates may need to reach equipment already operating at customer sites. Manufacturers also need defined processes through which vulnerabilities can be reported, evaluated and responsibly communicated.
This raises practical questions for the industrial world: How long will a product be supported? How can deployed devices be updated? How are vulnerabilities received and assessed? What happens when a security issue emerges years after commissioning?
These are no longer questions only for cybersecurity specialists. They increasingly involve R&D, engineering, product management, quality and after-sales organizations. Cybersecurity is becoming part of product lifecycle management itself.
From certification to a continuous cybersecurity process
For EXOR International, achieving IEC 62443-4-1:2018 Maturity Level 2 certification for its Secure Development Lifecycle represents an important milestone, but not the end of the journey.
The company is continuing this work at product level, pursuing IEC 62443-4-2 certification for selected new-generation hardware. The distinction is significant: secure products require both security-oriented engineering processes and technical security capabilities implemented in the products themselves.
This is also why vulnerability management cannot begin only when regulation requires it. EXOR International has already established a public vulnerability disclosure process through which external security researchers can report potential security issues affecting its products and services. The process defines reporting channels, coordinated disclosure principles and procedures for handling reported vulnerabilities.
Together, these initiatives reflect a broader principle: cybersecurity is not a certificate to display, but a capability that has to be built, maintained and demonstrated over time.
Cybersecurity is becoming industrial engineering
The transformation taking place in 2026 goes beyond the CRA or any individual standard. Industrial cybersecurity is moving from perimeter protection toward lifecycle resilience, from individual security features toward secure development, and from one-time compliance exercises toward continuous responsibility.
For OEMs and industrial technology providers, this changes the fundamental question. It is no longer only: “Is this product secure today?” It increasingly becomes: “Can we develop, maintain, update and support this product securely throughout its operational life?”
At EXOR International, this is the direction behind the work already underway: a certified secure development process, structured vulnerability management and an ongoing path toward technical security requirements implemented and assessed at product level.
Because ultimately, cybersecurity is not a certificate to display. The certificate matters when it demonstrates something real: processes and products engineered to remain trustworthy as technology, threats and regulatory requirements continue to evolve.
