Richard Seidl
Standards for secure software development are often seen as a necessary evil - but what if a team actually learns to appreciate them? The implementation of IEC 62443-4-1 can become a catalyst for better collaboration if process training is combined with practical testing strategies and security requirements are systematically translated into testable features. The decisive factor here is not the perfect initial certification, but a living process with internal audits, dedicated knowledge transfer and the courage to creatively solve independence in software testing, even in small teams.
Podcast Episode: Practical and safe development with IEC 62443-4-1
In this episode, I talk to Holger Santelmann about how his team not only implemented the IEC 62443-4-1 standard for secure software development, but actually learned to love it. Holger shows how they turned a dreaded paper monster into a living process that improves collaboration between development and software testing instead of hindering it. Particularly exciting: instead of dry compliance exercises, they have developed training courses that break down each security requirement in practical terms, established test collaboration meetings and creatively solved the Independence of Testers via competence centers.
"If there are a lot of issues in the pull request, then a developer has not tested whether it is still running." - Holger Santelmann
Holger Santelmann holds a degree in media informatics (FH) and has more than 20 years of experience in software development. He started as a senior software developer at M&M Software GmbH and in recent years has increasingly specialized in release and test management. As head of the Competence Center Quality Engineering, he continues to drive the topic of quality assurance within the company M&M Software GmbH and supports the software development process.
Highlights der Episode
- Standard 62443-4-1 almost completely fulfills the Cyber Resilience Act - perfect toolbox for secure development.
- Dedicated security training per requirement is more effective than abstract cert training for all employees.
- Test Collaboration Meetings before each feature eliminate surprises in the pull request and create real independence.
- Security features must be flagged, reviewed and approved by qualified testers - dual control is mandatory.
- Gap analysis shows: Evaluate the existing process, then choose the standard - not the other way around, otherwise it will be expensive.
With standards to more security: Why IEC 62443-4-1 helps us to stay awake
Why standards can be more than a chore
Many people freeze when they hear the word "standard". This is understandable, as such a document rarely brings joy to everyday life. Nevertheless, standards are becoming increasingly important when it comes to the development of secure software. Every company that develops products for industry is noticing this. The discussion between Speaker A and Speaker B at the QA Day in Frankfurt was about precisely this: Is security just bureaucracy, or can there be added value for the entire organization behind it?
What is behind IEC 62443-4-1?
IEC 62443-4-1 is a process standard that describes how to develop secure software, especially in the industrial sector. It is about security - from the initial idea to design, implementation, testing and maintenance. At each step, the standard asks: Is everything designed in such a way that it protects against attackers and reduces risks? Documentation and the question of which components (such as third-party libraries) are used are also critically examined.
What is new is that the Cyber Resilience Act (CRA), which will be introduced in the EU at the end of 2024, will make much of this mandatory. Manufacturers must prove that they activate security technologies at the time of delivery, disclose vulnerabilities and provide improvements. IEC 62443-4-1 serves as a guide to help manufacturers meet all of these requirements.
Security as a joint team process
Of course, standards can simply be worked through like a must. But that's not exactly what Speaker B and his team did. They took the opportunity to scrutinize internal processes and rebuild them together. First, they determined how independence of testing works. You need different perspectives: developers do not test their own work alone. The four-eyes principle, role allocation and regular reviews are mandatory.
An exciting point: it's not just the technology that matters, but also how teams learn to deal with security. That's why they started with process training for everyone: developers, requirements engineers, quality engineers - everyone received training on what is important now and how it is implemented in everyday life.
Practical tips from the changeover
Of course, such a change takes time. Speaker B's team invested a year in adapting the processes before the dedicated training sessions came. Instead of throwing everyone in at the deep end, they started with a gap analysis: what are we already doing, what is still missing for the new standard? In this way, existing good practices were retained and only what was really missing was added.
With manuals, templates and training courses, security became something tangible. Every step - from requirements engineering to test design and review - was documented and discussed. In this way, processes remain transparent and no one is at a loss when things get serious.
The team also documented exemplary test cases for security requirements in a wiki. Anyone asking: "How do I actually check audit logging?" - can find answers and inspiration there.
Collaboration and feedback: Why learning comes from it
The real value of the process is revealed in the collaboration. Developers and testers exchange ideas in so-called test collaboration meetings: Which test types fit, what is there to consider, where is automation worthwhile and what remains manual? The aim is to eliminate surprises - preferably as early as possible. Errors, misunderstandings or uncertainties are uncovered before implementation. This saves time and nerves, and ultimately creates trust in the product.
Learning does not end after the rollout. Internal audits, feedback rounds and obtaining expert opinions provide new insights. No process is ever finished - and that is exactly what makes it alive.
Those who see standards only as a burden overlook an important advantage: they provide structure and force reflection. When teams tackle the requirements together, adapt them and live them, more than just a checklist is created. It's about consistency, transparency and cooperation, which ultimately not only protects against hackers, but also makes everyday life in the company clearer and more secure. And sometimes this also brings joy - even with a standard like IEC 62443-4-1.