Implementing IEC 62443-4-1 Processes That Development Teams Actually Use

The reporting obligations under Article 14 of the Cyber Resilience Act (CRA) apply from September 11, 2026. The remaining requirements apply from December 11, 2027. By then, many manufacturers will have processes according to IEC 62443-4-1 in their quality management system. Whether their development teams actually work by them is the harder question.

IEC 62443-4-1 describes the secure product development lifecycle in eight practices. They range from security management through requirements, design, implementation, and verification to handling reported vulnerabilities and providing updates. The standard requires you to define, document, and apply these activities. It does not prescribe what your workflows look like in detail.

The CRA requires documented processes and leaves the workflows to you

The CRA, Regulation (EU) 2024/2847, requires evidence of processes in several places. Annex I, Part II requires vulnerability handling processes. Article 13(8) requires you to handle vulnerabilities effectively for the support period. Annex VII lists the description of these processes as part of the technical documentation. The goal behind this is repeatability. A product should get the same security properties regardless of which department develops it and who is on vacation.

The CRA does not prescribe specific workflows. It requires results and evidence, and the same applies to IEC 62443-4-1 and to the horizontal standards of the EN 40000 series. Your development works today. It must, or no products would reach the market. That makes your existing workflow the right starting point.

A compliant process set takes two months, living it takes a year and a half

The documents themselves are done quickly. In our projects, adapting and approving a process set that complies with IEC 62443-4-1 typically takes about one to two months. Until all departments work by it, 6 to 18 months can easily pass. The gap between these two figures is the actual project.

It takes longest where teams do not yet work by processes at all. Then you must introduce not only the content but also the habit of looking into a process system in the first place. If you ignore this, you plan the approval of the documents as the end of the project. You then face an audit in which the instructions and the daily work do not match.

Why implementation fails in the departments

We introduced processes according to IEC 62443-4-1 at a manufacturer of connected devices that develops firmware and some apps. A quality management system existed, with general development processes, even compliant with ISO/IEC 15288. For day-to-day development, however, it had no relevance. The departments had rebuilt their own processes in the wiki, describing how they actually worked.

The central system was too complex for a modest software team. It would have been appropriate for distributed hardware development or for automotive, but not for firmware and apps.

During the revision, it also turned out that nobody followed the central processes. One department did not even know the group-wide requirements. This only came to light when we wanted to add the security-specific requirements. Until then, the CTO had assumed that all departments followed them. If you find process descriptions in a department's wiki, you need no further analysis: the employees gave up on the central system long ago.

Overly generic processes end at plan, do, check

The revision was the harder part. Many participants pictured bloated documents with complicated approvals and therefore kept the workflows abstract. The more generic a process is, the less of it remains. In the end, you are left with plan, do, check, and nobody can work with that.

A manufacturer with three or four different products does not need one process that covers everything at once. For each product type, it needs instructions on what to do, with which tool, and what the result must be. Add a confusing system in which countless Word files refer to each other, and the documentation is of no use to development anymore.

Documenting the ideal creates permanent work

A common mistake is to describe the workflow you would like to have. The process looks clean but has nothing to do with development. From that moment on, you maintain two worlds, the real one and the documented one. You must keep the parallel world alive for every audit.

A process does not have to be academically clean to be compliant. It must describe what happens and deliver the results that the standards and the regulation require.

Templates are the benchmark, not the starting point

Good templates show you what must exist at the end. You compare this target picture with your own situation and handle three cases:

• If the template or process step does not exist in your organization yet, adopt it.
• If it partly exists, complete it.
• If what you have is sufficient, leave it as it is and introduce nothing new.

If you instead lay a complete template package over the organization, you build a second structure next to what employees do every day. The result is again a process that reaches nobody, only this time in someone else's handwriting.

For a template to be used day to day, people must be able to fill it in without much thought. Our templates are written in plain language. They describe what to do instead of explaining in the abstract how things would be done in the world of standards. That is why they include examples and filling guidance, among other things, so that a developer can start right away.

Good and bad processes differ in six places

Whether a process is used day to day depends on a few characteristics. The comparison below summarizes what we see on both sides in projects:

Characteristic	Good process	Bad process
Starting point	the workflow people follow today	the ideal picture or the template package
Level of detail	specific instructions per development type	plan, do, check for everything
What comes with it	templates with examples and filling guidance	empty forms without instructions
Language	simple, the action comes first	treatise in standards vocabulary
Findability	filterable by role, target system linked	Word files with references to the IDs of other documents
Purpose of the structure	users find their tasks	the auditor finds the evidence

Which tool you use is secondary. What matters is that employees can access it and filter by their role. They must see immediately what to do in their situation and which tools or templates to use for it.

Process debt from CE practice comes due with the CRA

If you have collected the evidence for CE marking at the end of development so far, you have built up debt. Under the CRA, this evidence is created during development. The frustration and panic we currently see around the CRA often come from paying off this old process debt.

Manufacturers that already run development in a structured way have technical topics to clarify for the CRA, and the process side is done in a few weeks. Still, every company has room for improvement. We therefore think it is wrong to push the topic to 2027. By then, the technical tasks are still open, consultant capacity is scarce, and the 6 to 18 months until daily use still lie ahead. A new process does not run smoothly from day one, and that is exactly why you need the time before December 11, 2027.