Your IEC 62443-4-1 SDLC is not compliance until your developers live it

The question behind the question

I understand where the question comes from. AI has become part of how product teams work, and it is genuinely good at producing structured text quickly. Ask it for a secure development lifecycle and you will get something that looks right: eight practices, roles, procedures, templates. For a team facing the Cyber Resilience Act, that looks like the finish line.

But an SDLC is not compliance. It is a description of work that has to happen, release after release, in the hands of people who were not in the room when it was written. IEC 62443-4-1 asks for a defined process and evidence that the process was followed for each product. The first half fits in a document. The second half only exists if the development teams actually live the process. No generator produces that for you.

The first surprise: you are not allowed to give the standard to the AI

The second part of the conversation surprised them more. The plan was to upload IEC 62443-4-1 into an AI tool and let it build the lifecycle from the source text. The IEC Webstore terms do not allow that: IEC publications may not be introduced into AI tools, public or privately licensed, without IEC’s express permission. Uploading the standard is not a clever shortcut. It is a breach of the licence you bought it under.

That leaves the AI working from general knowledge about the standard rather than the text itself, and the result reads convincingly while missing exactly the detail an assessor checks. Someone who knows the requirements still has to read the standard, decide what each practice means for this organisation and these products, and write that interpretation down. AI can help draft and structure that interpretation. It cannot replace the person who is accountable for it.

Writing the lifecycle was always the small part

Even done properly, building the SDLC is painstaking work. But in every certification project I have been part of, it was the smaller share of the effort. The larger share started the day the document was approved, when it had to become the way people actually work.

Picture the developer on the receiving end. Their backlog is full, their release date is fixed, and security has so far been something the platform or a separate team handled. Now they receive a hundred pages describing threat models, security requirements, coding rules, verification activities and release gates. They will not read it. Not because they are careless, but because nothing in their week makes room for it. A lifecycle that is handed over as a document stays a document.

What a real handover involves

The teams I saw succeed treated the handover as a project in its own right, with its own steps and its own owner:

• Separate the management part from the development part. Governance, responsibilities, supplier requirements and process reviews belong to management. Developers need a short, practical version: what to do on a feature, a pull request and a release. Handing everyone the full document serves neither group.
• Find the right people. Every activity needs a named owner with genuine interest in security, not a line on an org chart. I wrote about why that decides everything in It works when interest meets expertise.
• Build the expertise before the work starts. Assess what the owners know against what their role needs, and train where there is a gap. IEC 62443-4-1 asks for exactly this (SM-2 and SM-4), and it is the step that turns an assigned task into a practised one.
• Put the process where the work already happens. Definition of done, pull-request templates, CI checks and release gates carry the lifecycle into daily work far better than a document portal does.
• Start small and prove it. Run the full lifecycle on one product and one release first, fix what does not fit, then roll it out. The first release is where the handover is really tested.

Then the real work starts, and this is what gets lost

Only once people, expertise and tooling are in place can the lifecycle actually run. And that is where a long list of obligations begins, each easy to lose when a busy team is left on its own with the document:

• Secure by design — threat modelling that happens before the design is fixed, not reconstructed afterwards for the file.
• Security requirements — requirements that are derived, reviewed and traceable to tests, not copied from a template.
• Secure implementation — coding rules, reviews and static analysis that are actually enforced.
• Security verification and validation — requirement tests, threat mitigation tests, vulnerability and penetration testing, with the independence the standard asks for.
• Vulnerability handling and disclosure — intake, triage and coordinated disclosure, and under the CRA, reporting of actively exploited vulnerabilities since 11 September 2026.
• SBOMs and security updates — a component inventory kept current, and updates delivered securely across the whole support period.
• Security guidelines for users — hardening, secure operation and decommissioning guidance that matches the product as shipped.

Each of these has its own evidence, its own owner and its own ways of quietly failing. None of them is solved by having a well-written lifecycle document. All of them are solved by people who understand why they matter and have the time and support to do them.

Where AI genuinely helps

None of this is an argument against AI. I use it, and I recommend it to the teams I work with. It is excellent at drafting templates and work instructions from your own interpretation, explaining a requirement to a developer in plain language, checking a pull request against your policy, and keeping documentation aligned with the code. I described that last part in detail in Let AI write your IEC 62443-4-1 SDLC documentation.

That approach starts from a policy your own people wrote, and every change the AI proposes still needs an engineer who can judge it before it is merged. That engineer is exactly who the handover is for. AI makes a well-handed-over lifecycle cheaper to run; it does not replace the handover. What AI does not do is decide what your process should be, own it, or make a development team care about it. Those remain human jobs, and they are the jobs an auditor looks at most closely.

What I take from it

The customer’s question was a good one, and I expect to hear it more often. My answer has not changed: AI makes writing the lifecycle faster, and that is welcome. But compliance with IEC 62443-4-1 and the CRA is not a document you produce. It is a way of working that has to take root in teams that already have too much to do. Getting it there, with the right people, the right expertise and the practices built into daily work, is the part that decides whether the lifecycle survives its first release.