NOVEMBER 3, 2025

4 MIN.

Secure software development in manufacturing – A project report from a development manager

Cybersecurity is no longer a buzzword. It is an essential requirement. In the coming years, regulations such as the Cyber Resilience Act (CRA) and NIS-2 Directive will make security for networked products mandatory, including verification across the entire life cycle. In our projects, we are constantly reminded of the depth of these requirements, and the significant impact that occurs when security is understood and practiced as a process, rather than treated as the final feature before software release.

Why secure software development matters

When using software in a networked production environment, the pressure is not only to prevent attacks and downtime, but also to comply with regulations such as the CRA or NIS-2 Directive. Both regulations require companies to anchor IT security as an integral part of quality assurance and compliance throughout the development process, not just at the end. From the start of the debate around the CRA, it was clear that this affects not only compliance, but also the entire development culture. Secure-by-Design, vulnerability handling, and verifications are no longer optional extras – they are mandatory.

The fundamentals stay the same – but are often missing

In projects, we often note that basic requirements are missing: Clear requirements with bidirectional traceability of

• Requirements
• Architecture
• Implementation
• Test cases

are not a luxury, but a basic condition for reliable delivery at a reasonable level of effort.

Due to the requirements of the CRA, we are obliged to provide free security updates for the entire service life of our products, even years later. Without this foundation, it becomes extremely expensive to make the necessary changes, especially architectural ones, as all features would need to be reverse-engineered. It is also uncertain if the software will still work as it did before. A note to managers: The business model must also be adapted to keep costs under control.

To create this foundation, we aligned our agile development processes with A-SPICE years ago. Why? Because A-SPICE provides an excellent structure for planning, implementation, and verification — creating a solid basis for embedding security..

Security as a process – The core element

To establish security as an integral part of our development landscape, we have aligned it with IEC 62443-4-1, ISO 27001, TISAX, and A-SPICE. As development manager, it was important to me that developers could implement security clearly and easily, without compromising verification and auditability.

Here are the building blocks that have proven effective in practice:

Risk assessment & threat modeling
We take a risk-based approach: Identified risks determine the measures we prioritize, and which we decide not to implement. That helps us understand where we need to start, and which measures actually work. Threat Modeling is the logical next step, allowing attack vectors to be systematically assessed as risks, and mitigated before they cause costly failures.

Secure architecture & defense-in-depth
Security by design is non-negotiable for us. In edge.SHIELDOR, we implemented several levels and structures – vertical and horizontal – to clearly separate IT and OT. This architecture not only increased security, but also accelerated development, as defined security zones and interfaces make it easier to work on the source code.

Secure design & coding policies
We introduced secure-design and secure-coding-standards to provide developers – whether or not they specialize in security – with clear guidance. Tool support, such as static code analysis, is essential. Although it was challenging at first, we have consistently resolved all findings, and configured the pipelines with strict rules to ensure stability.

Security testing (including system tests and pen tests)
We do not rely on tools alone. In addition to automated scans (SAST, DAST, Fuzzing), we conduct system tests with a focus on security, alongside internal and external penetration tests. Using exploratory manual testing, our experienced security developers continue to uncover issues that the tools have overlooked.

Release management as risk management
We view every release as a risk decision. While we cannot completely rule out all errors, we can make them less likely to occur. Our decisions are based on aggregated KPIs, evaluation of all security-related bugs, vulnerabilities and other risks, alongside third-party component analysis (SBOM-supported): Only low-rated risks are released, with higher risks only being released with documented and effective mitigations in place. This is time-consuming, but it enables us to identify if a release is truly mature – before it fails for the customer.

Quality Gate: Internal audit by QA
Before a release is published, our QA team performs an independent internal audit to verify that the product has been developed, tested, and checked according to our processes. This Quality Gate acts as a benchmark and incentive.
At the same time, it is one of the most important pillars of CIP in practice, as we take NCs and PIs seriously.

Vulnerability management & PSIRT
Even after the release, vigilance is essential. We established a vulnerability management process and introduced software composition analysis tools for the SBOM creation and analysis. We use CVSS to assess whether vulnerabilities could be exploited in our customers’ environments and have defined clear SLAs for security patches. This approach ensures CRA-compliant notifications within 24 or 72 hours.

Processes, workflows & audits
We do not produce documentation for the shelf – it is designed for active use and efficient collaboration. Verifiability is created automatically. Regular internal process audits help us to close gaps and live by the principle of continuous improvement.

The result: In December 2024, we were certified by TÜV Rheinland in accordance with IEC 62443-4-1 ML-2. Confirmation that our efforts were worthwhile.

Regulatory pressure: CRA & co.

The CRA centers security throughout the entire product life cycle – with painful penalties for non-compliance. In many external projects, we observe that security and the CRA can create uncertainty and even inaction. Yet, as demonstrated above, these topics are all manageable and can easily be replicated using processes and workflows.

When asked, ‘Where do we start?’, my answer is always: Begin with a GAP analysis. It reveals the current status and defines the next steps. Although the CRA is not (yet) fully defined in detail, IEC 62443-4-1 and -2 serve as excellent references. That’s how we started, and this set us on the right course.

Conclusion

Security doesn’t begin at the firewall, but with the design. The full application of the CRA will begin in December 2027, with the first reporting obligations taking effect from September 2026.
We’ve learned that those who think of security as a process are the ones who succeed: fewer incidents, faster audits, and greater trust. But changes to the development process and even to products take time – which is why now is the time to act.

Autor: Dr. Simon Walz

Dr. Simon Walz is Head of Product Development at TRIOVEGA. With over ten years of experience in industrial software development, and a strong focus on IT and OT security, he is responsible for the development of secure software solutions, and the implementation of standards such as IEC 62443 in practice. He also supports customer projects from the technical conception through to the implementation of evolving protection measures.

Book your individual consultation!