Practical and safe development with IEC 62443-4-1

IEC 62443-4-1 is a process standard for secure software development in the industrial automation environment. It describes the entire development process from design to maintenance and fulfills many of the requirements of the Cyber Resilience Act. Core elements include security requirements, independent testers, review processes, threat modeling and seamless traceability between requirements, implementation and testing.

Key Takeaways

• As a process standard, IEC 62443-4-1 covers a large part of the requirements of the Cyber Resilience Act, which will become mandatory from December 2027 and will force manufacturers of digital products to provide demonstrable cyber security.
• Independence of Testers specifically means that testers and developers must not report to the same manager, which requires organizational solutions such as a competence center, especially in small companies.
• A gap analysis of the existing process before the standard is introduced saves considerable effort because it shows how large the actual delta is before investing in training and certification.
• Test collaboration meetings, in which developers and QA engineers jointly define test strategies for each backlog item, prevent late surprises in the pull request and deliberately move unresolved issues to the left of the process.
• Process training not only serves to fulfill standards, but also reactivates implicit process knowledge that has been lost in day-to-day work and creates traceability awareness across the team.

What 62443-4-1 regulates and what it stands for

IEC 62443-4-1 is a process standard for safe software development in the industrial automation and control environment. It describes how software is to be developed safely from the design and implementation through to the maintenance phase.

The standard is part of a larger family of standards. The “-1” is the process part, i.e. the specifications for the way in which development is carried out. The “-2” provides a catalog of requirements for products and components that are to be considered safe.

Both parts are interlinked. Anyone wishing to be certified in accordance with 62443-4-2 must first go through the entire process from “-1” and have fulfilled all the requirements.

How the standard and the Cyber Resilience Act complement each other

62443-4-1 functions as a toolbox for the process requirements of the Cyber Resilience Act. The CRA forms the legal framework, the standard provides the tools to implement the required processes.

The Cyber Resilience Act came into force in December 2024. It obliges manufacturers of digital products to demonstrate cyber security in their products, i.e. to develop secure ones. This also applies to existing products. the first reporting obligations to disclose vulnerabilities will begin in 2026, and the CRA will take full effect from December 2027.

Specifically, the CRA requires several things: software should be secure as delivered, encryption should be activated and the attack surface should be minimized by disabling unnecessary interfaces. There will also be vulnerability management with assessment and updates for end customers as well as requirements for documentation.

One point forces manufacturers to be disciplined when it comes to external components. An evaluation scheme must be used to check whether a third-party library is even suitable in the current environment. In addition, the CRA requires a software bill of materials, or S-BOM for short, which describes all installed components, both internal and external.

The standard covers the process part, not the whole thing. For the content-related security requirements, 62443-4-2 comes into play; its catalog of requirements is imported into the in-house development and supplemented.

Why security requirements become marked features

In this way of working, security is made visible instead of being implicit. A security requirement leads to a security feature, and both are clearly marked as security-relevant.

This marking creates traceability. A feature that implements a security requirement such as logging is considered security-relevant. The tests that check this feature are linked to the requirement and are also marked as security-relevant.

The requirements come from several sources: from the 62443-4-2 catalog, from the Cyber Resilience Act, from internal specifications or directly from the customer. They can also arise from a threat model. Each requirement is analyzed to determine whether it fits the product. Some are of a technical nature and are aimed at hardware level, which then does not apply.

A review is carried out before implementation. This involves a security officer or architect, the product owner and a QA engineer, among others. The aim is to uncover errors in the document at an early stage before they make their way into the code. All those involved sign off the feature.

Security level determines the level of protection required

The security level determines how much effort goes into protection. 62443-4-2 recognizes four levels: from SL1 for intentional use to SL4, where a secret service is assumed to be the attacker.

Every product must fit into this grid. For this purpose, a document is created that describes the security context and the environment and derives the appropriate level from this. In practice, many products lie between SL1 and SL2 if no highly security-critical values are to be protected.

The selected level controls which security requirements are relevant and how high the security effort is. With SL2, this effort is already noticeably higher than with SL1.

How a small company ensures the independence of testing

The standard requires independence of testers for security-relevant requirements, which makes sense from the integration testing level onwards. Independence here means a four-eye principle in which testers and developers do not report to the same group leader.

This is a problem for a small company because the separation of personnel quickly becomes narrow. One solution is the organizational structure. At M&M Software, this rests on three pillars: the employees with their group leaders, the project business and the competence centers.

The groups are small, averaging up to eight or slightly more employees, who meet with the group leader once a week. Because the teams are professionally mixed, the likelihood of testers and developers reporting to the same group leader is reduced.

If the separation does not work, the competence center takes on a second function. The Quality Engineering Competence Center bundles the quality engineers and can act as an arbitrator if a developer and a quality engineer have a dispute and both report to the same person.

Why training is the most difficult part of implementation

The process itself was set up quickly, the trainings were the real work. While the process documentation was roughly completed in a year, the technical security training courses were much more time-consuming to create.

The introduction began with a designated person who had fully familiarized themselves with the topic of security. This was followed by a gap analysis: the existing process was compared with the target process and only the delta was rebuilt. Security had previously been included as a quality attribute, but had not been specifically identified.

This step is the most important advice for anyone who wants to introduce a standard. Look at your existing process, determine the delta to the target standard and calculate the costs against the benefits. Some standards mention another standard in a subordinate clause, which entails a whole rat’s tail.

The training sessions were divided into two groups. The process training sessions were for developers, requirements engineers, product owners and quality engineers. The QA engineers also went through the PO and development process training so that they know what to expect when reviewing a security feature.

The locations in China and India had to be convinced separately because the local markets test differently and the justification for EU requirements is not self-evident there. Training is therefore also a means of convincing people that built-in security makes sense.

Pseudo-features as a practical test fund

Instead of having every quality engineer start from scratch with every security requirement, a reusable knowledge base was built up. Each security-relevant requirement was broken down into a pseudo-feature and documented.

The trigger was a specific cost issue. An abstract security training course like the CSSLP brings a lot personally, but does not help directly with the testing of an individual requirement. Without a template, every QA engineer would have to rethink each requirement in order to find the appropriate Abuse tests.

The solution was based on the implementation guidance that already existed for many requirements. A pseudo-feature with test conditions, test objectives and sample test cases was created for each requirement and stored in a central wiki.

The benefits are evident in everyday life. Anyone who needs to test audit logging and does not know where to start will find ideas, a reference and the quintessence of the requirement in the wiki for reference. The training sessions were spread over around seven units, which anyone could attend.

The Test Collaboration Meeting brings security to the left

The biggest practical lever is a meeting in which developers and QA engineers jointly define the test strategy for a work package. This shifts clarification and security issues to the beginning of the implementation instead of the end.

In the test collaboration meeting, the team of a product backlog item meets with the QA engineer, who acts as a quality coach. He contributes the acceptance view, the developers know the technical specification. Together they clarify whether the work package is understood and which questions still need to be addressed to the product owner.

A helpful image for this is that each backlog item is like a small waterfall model. At the top are the acceptance criteria, below that a small system design, then the component level with integration testing, at the bottom the unit testing level.

The test strategy emerges from this meeting as a documented result. It determines which test types and procedures are used and what is tested at which level. Manual acceptance tests are expensive, which is why it is important to cover as many permutations as possible at the lower levels through clever editing.

The sequence follows a clear principle:

If you have run through the standard workflow dozens of times anyway, you should automate it and put the manual energy into a clean exploratory testing. That way, there will be no surprises at the end, no subsequent “Is that how it’s supposed to behave?” from the product owner.

How specifications for coverage and code reviews work

The implementation follows fixed best practices and the code is always reviewed. For safety-critical components, branch coverage should be as close to 100 percent as possible; for less relevant parts such as getters, it can be less than 80 percent.

The code review in the pull request is the place where weaknesses in the preparatory work become apparent. If a lot of issues occur there, either the test was not carried out properly or the strategy was not written down clearly enough.

Anyone who writes test cases for security-relevant features must be qualified and have undergone the appropriate training. If they are not qualified, the test cases must be approved by someone who is. For reasons of independence, penetration tests are completely outsourced to an accredited partner who also provides objective approval.

Why a standard must become a living process

A standard is only useful if it is put into practice instead of being filed away on paper. 62443-4-1 itself requires reflection and improvement, and it is precisely this mechanism that keeps the process alive.

Internal audits check in-house projects for process conformity and uncover where people have problems in practice. This results in continuous improvement and the feedback is fed back as advice, not as a reproach.

A recurring pattern: older employees have often implicitly been working according to the process for a long time, but are not aware that it even exists or where they can find it. Making the process visible and creating traceability is the real task.

The purpose of this traceability becomes tangible in an emergency. If an accident occurs, the design, implementation and tests are looked into. A test result that only says “passed” will not help. With security, the individual test steps count as proof that testing has really been carried out.

If I just say the test is passed, but I haven’t really tested it, how can I justify that? You want to dispel this mistrust.

• Holger Santelmann

The TÜV as an early indicator before the audit

A pre-audit by TÜV shows early on what is important in the subsequent audit. TÜV is not allowed to give advice, but it can provide feedback, and this feedback alone is a useful indicator.

You go into the pre-audit with the proposal for the adapted process and see what the auditor is looking for and what he wants to see. This makes the expectations for the actual audit concrete.

The first attempt is rarely without deviations. During the audit one year later, it is important that the deviations have been rectified and adequately addressed. It would be presumptuous to assume that nothing will be noticed the first time. This is also a learning process.

How small projects deal with overhead

The smaller the project, the greater the pressure of the overhead of the standard, and this is precisely where a lean response is needed. With large projects, the process establishes itself almost automatically; with small projects, the question quickly arises as to whether a separate test plan is really necessary.

The solution is a pre-filled master test concept, known internally as a QA plan, which combines the master and level test plan in one document. It is closely tailored to your own process and refers to the existing procedures so that you can go through it quickly for small projects.

There are also a few mandatory documents such as the project manual and the Secure Context and Environment document. This keeps the workload manageable without losing traceability.