Processes according to IEC 62443-4-1 can be set up in one to two months, but it often takes six to eighteen months before departments actually work by them. This explains why.
IEC 62443-4-1 describes the secure product development process in eight practices, from security management through requirements, design, implementation and verification to handling reported vulnerabilities and providing updates. The standard requires that you define, document and apply these activities. It does not prescribe how your procedures must look in detail.
The CRA requires documented processes and leaves procedures to you
The CRA, Regulation (EU) 2024/2847, requires evidence of processes in several places. Annex I Part II requires procedures for handling vulnerabilities, Article 13(8) requires that you treat vulnerabilities effectively throughout the support period, and Annex VII lists the description of these processes as part of the technical documentation. The idea behind this is repeatability. A product should receive the same security properties regardless of which department develops it or who happens to be on vacation.
The CRA does not prescribe specific workflows. It demands results and evidence, and the same applies to IEC 62443-4-1 and to the horizontal standards of the EN 40000 series. If your development works today — and it does, otherwise no products would reach the market — then your existing workflow is the right starting point.
A compliant process set is ready in two months, but lived-in after one and a half years
The documents themselves are finished quickly: adapting and approving a process set compliant to IEC 62443-4-1 typically takes about one to two months in our projects. It can take six to eighteen months until all departments actually work according to it. The gap between those two numbers is the real project.
It takes longest where teams don’t yet work by processes at all. In such cases you must introduce not only content but also the habit of consulting a process system in the first place. If you don’t account for that, you plan document approval as the project end and then fail the audit where procedure and daily work do not match.
Why implementation in departments fails
At a manufacturer of connected devices that develops firmware and some apps, we introduced processes according to IEC 62443-4-1. A QM system existed, with general development processes, even conforming to ISO/IEC 15288. For everyday development, however, it had no relevance. The specialist departments had rebuilt their own processes in the wiki to reflect their actual workflows.
The central system was too complex for a compact software team. For distributed hardware development or for automotive it would have been appropriate; for firmware and apps it was not.
During the revision we also discovered that nobody followed the central processes and one department didn’t even know the corporate-wide requirements. This only became apparent when we wanted to add security-specific requirements. Until then the CTO had assumed that all departments complied. If you find process descriptions in a department wiki, you don’t need further analysis: the staff have long since abandoned the central system.
Processes that are too general end at plan, do, check
The revision was the harder part. Many participants imagined bloated documents with complicated approvals and therefore kept the workflows abstract. The more generally a process is formulated, the less of it remains useful. In the end you get plan, do, check — and nobody can work from that.
A manufacturer with three or four different products doesn’t need one process that covers everything at once. What is needed is, for each product type, an instruction of what to do, which tool to use and what the expected result must be. If you add an opaque system in which countless Word files reference each other by ID, the documentation becomes useless for development.
The desire to document the ideal process creates ongoing work
A common mistake is describing the workflow you wish you had. The process looks neat but has nothing to do with actual development. From that moment on you maintain two worlds, the real one and the documented one, and you must keep the parallel world up for every audit.
A process does not have to be academically perfect to be compliant. It must describe what happens and produce the results that the standards and the regulation require.
Templates are the benchmark for comparison, not the starting point
Good templates show you what must be present at the end. You compare this target picture with your own world and handle three cases: if the template or the process step does not yet exist in your organisation, you adopt it; if it exists partially, you supplement it; if what you have is sufficient, you leave it and introduce nothing new.
If instead you place a complete template package over the organisation, you build a second structure next to what people do day to day. In the end you again get a process that reaches no one, only this time it bears an external handwriting.
For a template to be used in practice, it must be fillable without long thought. Our templates are written in plain language and describe what to do rather than abstractly explaining how things are handled in the standards world. Therefore our templates also contain examples and completion aids so a developer can start immediately.
Good and bad processes differ in six places
Whether a process is used in daily work is decided by a few characteristics. The following comparison summarises what we see on both sides in projects:
| Characteristic | Good process | Poor process |
|---|---|---|
| Starting point | the workflow that is lived today | the ideal picture or the template package |
| Level of detail | concrete instructions per development type | plan, do, check for everything |
| Supplied materials | templates with examples and completion aids | empty forms without guidance |
| Language | simple, action first | discourse in normative vocabulary |
| Findability | filterable by role, linked to the target system | Word files with references to other document IDs |
| Purpose of the structure | the user finds their tasks | the auditor finds the evidence |
Which tool you use is secondary. What matters is that employees can access it, filter by their role and immediately see what to do in their situation and which tools or templates to use.
Where do your development processes stand today?
In the IEC 62443-4-1 Readiness-Check you get a first assessment in minutes of where your development organisation stands today and which gaps should be prioritised.
Process debt from CE practice becomes due with the CRA
Those who used to assemble evidence at the end of development for CE marking have built up debt. Under the CRA this evidence must be produced during development. Much of the frustration and panic we currently see around the CRA comes from paying down these old process debts.
Manufacturers who already run structured development have technical issues to resolve under the CRA, and the process side is handled in a few weeks. Every company still has room for improvement, however. We therefore believe it is wrong to postpone the topic to 2027. Then technical tasks will remain open, consulting capacity will be tight, and the six to eighteen months until daily application will still lie ahead. A new process does not run smoothly from day one, and that is exactly why you need time before 11 December 2027.
Setting up processes that are used day to day
We compare your existing workflows against the requirements from IEC 62443-4-1 and the CRA and help you supplement what is missing.
Schedule a conversation now
