IEC 62443-4-1 is a process standard for secure software development in industrial automation. It covers the entire development process from design to maintenance and meets many of the requirements of the Cyber Resilience Act along the way. Its core elements are security requirements, independent testers, review processes, threat modeling and end-to-end traceability between requirement, implementation and test.
Key Takeaways
- As a process standard, IEC 62443-4-1 covers a large share of the Cyber Resilience Act, which becomes mandatory in December 2027 and requires manufacturers of digital products to demonstrate cybersecurity.
- Independence of testers means in practice that testers and developers must not report to the same manager. Small companies in particular need organizational answers, such as a competence center.
- A gap analysis of the existing process before introducing the standard saves a lot of effort, because it shows how big the real delta is before anyone invests in training and certification.
- Test collaboration meetings, where developers and QA engineers agree on the test strategy for each backlog item, prevent late surprises in the pull request and deliberately move open questions to the left.
- Process training does more than satisfy the standard. It brings back implicit process knowledge that got lost in daily work and builds awareness of traceability across the team.
What IEC 62443-4-1 Regulates and What It Stands For
IEC 62443-4-1 is a process standard for secure software development in industrial automation and control systems. It describes how to develop software securely, from design and implementation through to maintenance. Testing under IEC 62443 follows from that process: security requirements become flagged features, independent testers check them, and every test stays traceable back to its requirement.
The standard belongs to a larger family. The “-1” is the process part, meaning the rules for how development is done. The “-2” provides a catalog of requirements for products and components that are meant to count as secure.
The two parts work together. If you want certification under IEC 62443-4-2, you first have to go through the full process from the “-1” and meet all of its requirements.
How IEC 62443-4-1 and the Cyber Resilience Act Fit Together
IEC 62443-4-1 works as a toolbox for the process requirements of the Cyber Resilience Act. The CRA sets the legal framework, and the standard provides the tools to put the required processes in place.
The Cyber Resilience Act entered into force in December 2024. It requires manufacturers of digital products to demonstrate cybersecurity in their products, in other words to develop securely. That applies to existing products as well. The first reporting obligations for disclosing vulnerabilities start in 2026, and the CRA is set to apply in full from December 2027.
In concrete terms, the CRA asks for several things. Software has to be secure by default: encryption switched on, and the attack surface reduced by disabling interfaces that aren’t needed. On top of that come vulnerability management, with assessment and updates for end customers, and documentation requirements.
One point forces manufacturers to be disciplined about external components. An evaluation scheme has to establish whether a third-party library is suitable for the environment at all. The CRA also requires a software bill of materials (SBOM) that lists every component in the product, in-house and external.
The standard covers the process, not everything. The substantive security requirements come from IEC 62443-4-2, whose catalog is imported into your own development and extended.
Why Security Requirements Become Flagged Features
In this way of working, security is made visible instead of running along implicitly. A security requirement leads to a security feature, and both are clearly flagged as security-relevant.
The flag creates traceability. A feature that implements a security requirement, such as logging, counts as security-relevant. The tests that check this feature are linked to the requirement and flagged as security-relevant too.
Requirements come from several sources: the IEC 62443-4-2 catalog, the Cyber Resilience Act, internal guidelines or the customer directly. They can also come out of a threat model. Each requirement is analyzed to see whether it fits the product. Some are technical and aimed at the hardware level, and then they don’t apply.
A review comes before implementation. The participants include a security lead or architect, the product owner and a QA engineer. The goal is to catch mistakes in the document early, before they make it into the code. Everyone involved signs off on the feature.
The Security Level Decides How Much Protection You Need
The security level determines how much effort goes into protection. IEC 62443-4-2 defines four levels, from SL1, which protects against casual or coincidental violation, to SL4, where the assumed attacker is an intelligence agency.
Every product has to find its place in this grid. A document describing the security context and environment is created for this, and the right level is derived from it. In practice, many products land between SL1 and SL2 when there are no highly critical assets to protect.
The chosen level controls which security requirements apply and how much protection effort is needed. At SL2, that effort is already noticeably higher than at SL1.
How a Small Company Keeps Its Testers Independent
The standard requires independence of testers for security-relevant requirements, sensibly from the integration test level up. Independence here means a four-eyes principle in which testers and developers do not report to the same group lead.
For a small company, that is exactly the problem, because there are only so many people to separate. One answer lies in the organizational structure. At M&M Software, it rests on three pillars: employees with their group leads, the project business and the competence centers.
The groups are small, on average up to eight people or slightly more, who meet with their group lead once a week. Because the teams mix different disciplines, it becomes less likely that the tester and the developer on a task report to the same group lead.
If the separation still fails, the competence center takes on a second role. The Quality Engineering competence center brings the quality engineers together and can step in as an arbiter when a developer and a quality engineer disagree and both report to the same person.
Why Training Is the Hardest Part of the Rollout
Setting up the process was quick. The training was the real work. The process documentation was in place in about a year, while the subject-matter security training takes far more effort to build.
The rollout began with one designated person who worked their way fully into security. Then came a gap analysis: the existing process was compared with the target process, and only the delta was built from scratch. Security had already been part of the work as a quality attribute, just not labeled as such.
That step is the most important advice for anyone introducing a standard. Look at the process you already have, work out the delta to the target standard and weigh costs against benefits. Some standards mention another standard in passing, and that reference drags a whole chain of further requirements along with it.
The training fell into two groups. Process training covered developers, requirements engineers, product owners and quality engineers. The QA engineers also went through the process training for POs and developers, so they know what to expect when they review a security feature.
The sites in China and India had to be convinced separately, because the local markets test differently and the case for EU requirements isn’t self-evident there. Training is therefore also a way to convince people that built-in security makes sense.
Pseudo-Features as a Practical Test Knowledge Base
Instead of letting every quality engineer start from zero on every security requirement, the team built a reusable knowledge base. Each security-relevant requirement was broken down into a pseudo-feature and documented.
The trigger was a concrete cost question. An abstract security course such as the CSSLP is valuable for the individual, but it doesn’t directly help you test a single requirement. Without a template, every QA engineer would have to think their way into each requirement from scratch to find the right abuse tests.
The solution built on the implementation guidance that already existed for many requirements. For each requirement, a pseudo-feature was created with test conditions, test objectives and example test cases, stored in a central wiki.
The benefit shows up in daily work. If you have to test audit logging and don’t know where to start, the wiki gives you ideas, a reference and the essence of the requirement to look up. The accompanying training was spread across about seven sessions that anyone could attend.
The Test Collaboration Meeting Shifts Security Left
The biggest practical lever is a meeting where developers and a QA engineer agree on the test strategy for a work package together. It moves clarification and security questions to the start of implementation instead of the end.
In the test collaboration meeting, the team working on a product backlog item meets with the QA engineer, who acts as a quality coach. The QA engineer brings the acceptance view, and the developers know the technical specification. Together they clarify whether the work package is understood and which questions still need to go to the product owner.
One helpful picture: every 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 tests, and at the bottom the unit test level.
The documented outcome of the meeting is the test strategy. It defines which test types and techniques are used and what gets tested at which level. Manual acceptance tests are expensive, so the aim is to slice the work cleverly and cover as many permutations as possible on the lower levels.
The order follows a clear principle:
| Level | Purpose |
|---|---|
| Unit tests | Cover as many permutations as possible |
| Integration tests | Secure abuse tests and permutations at the technical level |
| End-to-end workflow without UI | Check flows without the interface |
| Automated UI tests | Secure standard workflows repeatably |
| Exploratory test / abuse test at the top | Follow up specifically on what broke |
If you have run through the standard workflow dozens of times anyway, automate it and put your manual energy into a proper exploratory test. That way nothing surprises anyone at the end, and there is no late “Is it supposed to behave like this?” for the product owner.
How Coverage and Code Review Rules Work
Implementation follows fixed best practices, and all code gets reviewed. For security-critical components, the target is branch coverage as close to 100 percent as possible. For less relevant parts such as getters, it can be below 80 percent.
The code review in the pull request is where weaknesses in the earlier work show. If a lot of issues come up there, either the testing wasn’t thorough or the strategy wasn’t written down clearly enough.
Anyone writing test cases for security-relevant features has to be qualified and have completed the relevant training. Without that qualification, someone who has it must approve the test cases. Penetration testing is fully outsourced to an accredited partner for independence reasons, and that partner also provides the objective acceptance.
Why a Standard Has to Become a Living Process
A standard only pays off if people live it instead of filing it away. IEC 62443-4-1 itself requires you to reflect and improve, and that mechanism is what keeps the process alive.
Internal audits check the company’s own projects for process compliance and show where people struggle in practice. That produces continuous improvement, and the feedback goes back as advice, not as blame.
A recurring pattern: long-standing employees often follow the process implicitly without realizing it exists or knowing where to find it. Making the process visible and creating traceability is the real task.
The point of this traceability becomes tangible when something goes wrong. After an incident, people look into the design, the implementation and the tests. A test result that only says “passed” is no help then. In security, the individual test steps are the evidence that testing really happened.
“If I just say the test passed across the board, but I didn’t really test it, how can I justify that? That is the mistrust you want to remove.”
(Holger Santelmann)
TÜV Pre-Assessment as an Early Indicator Before the Audit
A pre-assessment by TÜV shows early on what will matter in the actual audit. TÜV is not allowed to consult, but it can give feedback, and that feedback alone is a useful indicator.
You take the proposal for your adapted process into the pre-assessment and see what the assessor pays attention to and asks to see. That makes the expectations for the real audit concrete.
The first attempt rarely goes without findings. At the assessment a year later, what counts is that the deviations have been fixed and properly addressed. Assuming nothing will come up the first time would be presumptuous. That, too, is part of learning.
How Small Projects Handle the Overhead
The smaller the project, the more the standard’s overhead weighs, and that is exactly where a lean answer is needed. In large projects, the process establishes itself almost on its own. In small ones, the question quickly comes up whether a separate test plan is really necessary.
The answer is a pre-filled master test plan, internally called the QA plan, that combines the master test plan and the level test plans in one document. It is tailored closely to the company’s own process and refers to the existing procedures, so it can be worked through quickly for small projects.
Add to that a small number of mandatory documents, such as the project handbook and the document on the secure context and environment. The effort stays manageable without losing traceability.
Frequently Asked Questions
What is the difference between IEC 62443-4-1 and IEC 62443-4-2?
The “-1” is the process-oriented standard and describes how to develop securely: from design through implementation to maintenance. The “-2,” on the other hand, provides a catalog of substantive requirements for products and components. The two standards are interrelated. Anyone seeking certification under 62443-4-2 must first fully complete the process outlined in “-1” and meet its requirements.
When must manufacturers begin complying with the Cyber Resilience Act?
The Cyber Resilience Act took effect in December 2024. The first reporting requirements for disclosing vulnerabilities will begin in 2026, and the Act is scheduled to take full effect in December 2027. This affects manufacturers of digital products who must demonstrate cybersecurity compliance, including for existing products, not just new developments.
Is IEC 62443-4-1 sufficient to cover the Cyber Resilience Act?
No. The standard covers the process aspect and serves as a toolkit for the process requirements, while the CRA provides the legal framework. The substantive security requirements are drawn from the 62443-4-2 catalog. In addition, the CRA requires a software bill of materials and an evaluation scheme to determine whether a third-party library is even suitable for the specific environment.
What does “independence of testers” mean in practice?
This refers to a four-eyes principle in which testers and developers do not report to the same team leader. Independence is required for security-related requirements, ideally starting at the level of integration testing. Small companies address this through organizational structure: small, cross-functional teams reduce the likelihood of a shared reporting line, and a center of expertise can act as an arbitrator.
Where should you start before introducing a standard into the development process?
With a gap analysis. The existing process is compared to the target process, and only the differences are addressed. Often, security is already incorporated as a quality attribute without being specifically labeled as such. Weigh the costs against the benefits before investing in training and certification. Some standards mention another standard in passing, which entails significant additional effort.
How do you prevent testing and security issues from only coming to light in the pull request?
By holding a meeting at the start of each work package, during which developers and QA engineers jointly define the test strategy. The QA engineer provides the acceptance perspective, the developers provide the technical specifications, and any open issues are escalated to the product owner. If issues pile up later during the code review, it means either the testing was inadequate or the strategy wasn’t documented clearly enough.
Why isn’t a “passed” result sufficient for security-related tests?
Because after an incident, design, implementation, and tests are all scrutinized. A blanket “passed” does not prove that testing actually took place. In security, the individual test steps serve as proof. This is precisely why security requirements, the resulting features, and the associated tests are flagged and linked together.
How do you keep compliance efforts manageable in small projects?
By using a pre-filled master test plan that combines the master and level test plans into a single document and references existing procedures. This allows for a quick review of small projects. In addition, there are only a few mandatory documents, such as the project handbook and the description of the secure context and environment. For large projects, the process establishes itself almost automatically anyway.
