Secure SDLC
IEC 62443-4-1 tells you what a secure development process must achieve. It never tells you how it should work in your company, with your products, your team size, and your toolchain. We build that lifecycle, then onboard it into your AI tooling so the evidence keeps pace with the code.
Why transform
The standard is written to apply to any manufacturer of industrial products, from a two-person firmware team to a multinational. That generality is precisely why it cannot be adopted as-is: it specifies outcomes and leaves the process design to you.
A downloaded policy set fails for a simple reason. An auditor does not assess your documents against the standard — they assess whether your organisation does what the documents claim. A lifecycle describing work nobody performs produces findings faster than having no document at all.
So the goal is not documentation that mentions the standard. It is a lifecycle your engineers follow because it fits how they already work, which happens to produce audit evidence as a by-product.
Stage 1
Every practice is scored separately in an audit, so an uncovered practice caps your maturity result no matter how strong the others are. We work through all eight, in the order that lets each one feed the next.
Name an accountable process owner, establish security champions inside the product teams rather than a detached central function, and assess actual security expertise against the roles the process needs. Gaps become a training plan with records — competence is auditable, not assumed. Also covers third-party and open-source component controls, and the security of the development environment itself.
Define the product security context — where the product is deployed, what it connects to, what it is trusted to do, and which threat actors matter. Build the threat model on that context, then derive security requirements from it so each one traces back to a threat rather than to a generic checklist.
Translate requirements into design: trust boundaries, least privilege, failure modes, and layered controls so no single defence is load-bearing. Design reviews and threat model updates happen at defined points in the lifecycle, with findings tracked to closure instead of noted and forgotten.
Adopt a documented secure coding standard for each language in use, with linters and static analysis enforcing what can be automated. Implementation review then verifies that the security design was actually realised in the code. This practice governs AI-generated code exactly as it governs hand-written code.
Four distinct activities the standard treats separately, and auditors check individually: functional testing of the security requirements, threat mitigation testing against the threat model, vulnerability scanning of code and dependencies, and penetration testing. Each needs a plan, a competent tester, and a record.
A single intake route for internally and externally reported vulnerabilities, consistent severity scoring, impact analysis across every affected product version, and a coordinated disclosure process. This is the practice the Cyber Resilience Act leans on hardest, and it is more than patching.
Qualify updates before release, deliver them through an integrity-protected channel, and document the support period for each product. Remediation timelines become a committed service level you can evidence — including how you reach devices that are rarely online.
Security guidelines are a deliverable to your customers, not internal evidence: hardening guides, secure configuration and integration guidance, defence-in-depth expectations for integrators, and secure decommissioning. Frequently the weakest practice, because it is the one nobody owns by default.
Definition of done
Two things separate a lifecycle that passes from one that stalls. The first is an unbroken chain from threat to release. The second is a maturity target agreed up front, so "transformed" has a measurable meaning.
A broken link is the most common audit failure we see. Not a missing control — an existing control nobody can connect to the requirement it satisfies, or a requirement with no test that proves it works.
ML 1 means the practice happens but is undocumented. ML 2 means it is managed and repeatable. ML 3 means it is defined and practised organisation-wide. Most manufacturers need ML 2 – ML 3, and not necessarily the same level for every practice. Setting that target per practice is what converts an open-ended programme into a plan with an end.
Stage 2
The real cost of IEC 62443-4-1 is not deciding what to do. It is producing and maintaining 47 requirements worth of records, release after release, while the product keeps changing. That is the cost AI reduces — the throughput of evidence, not the accountability for it.
A full loop with no human in it is the version an auditor attacks first. Three boundaries keep the automation defensible.
SVV expects verification to be independent of implementation. If the same agent writes the code and the tests that pass it, that independence is gone. Generation and verification stay separated, with a named human owning verification.
SM requires identified, trained, competent people. Competence is a property of your organisation, and no tool can hold it on your behalf. Records name the accountable humans; AI never appears as the qualified party.
AI drafts, a named human reviews and approves, and the approval is the artefact — with a version, a date, and an owner. Evidence regenerated on demand also changes between audits, so output is committed and versioned like any other controlled document.
Industrial customers often carry contractual or export restrictions on source code leaving the organisation, and your development environment is itself in scope under SM-7. Before anything is onboarded we agree the tenancy model, data retention and training guarantees, repository access scope, and how secrets are kept out of prompts and logs. That decision belongs in your lifecycle documentation, because an auditor will ask about it.
Working together
Almost nobody starts from nothing. You have release procedures, design reviews, a quality system, perhaps a functional-safety lifecycle. IEC 62443-4-1 does not ask you to throw any of that away — it asks you to show that what you do covers the eight practices and leaves evidence behind. Which of these two routes applies is the main thing the first step establishes.
When security work does happen, but is undocumented, or differs between teams and product lines.
We design the process around your products and write the procedures, templates and gate criteria together with your engineers rather than handing over a manual. Your team owns it at the end, and we are there while it is built and while the first real release runs through it.
When an established process exists — ISO 9001, ASPICE, a safety lifecycle, or a mature agile setup.
We map your existing stages, roles and artefacts onto the eight practices, keep everything that already conforms under the names your teams already use, and add only what is genuinely missing. Renaming a working process to match a standard buys resistance, not compliance.
Most organisations land between the two: some practices adopted almost unchanged, others built from scratch. The assessment establishes which is which per practice, so the plan follows your process instead of a template.
Engagement
The route changes what happens inside each step, not the order of them. In both cases we stay involved through the pilot rather than delivering a document and leaving you to apply it.
Get in touch
A short description of what you build, how your teams are organised, and what you are working towards is enough to start. We will come back with which route fits, where we would begin, and what the work would involve for your team.
We reply within two working days.
Full contact detailsPlease keep a first message free of confidential technical detail and trade secrets. Once we reply we can agree an encrypted channel for anything sensitive.
Prefer to start with data rather than a conversation? The gap assessment scores your current lifecycle per practice and returns the missing evidence artefacts — it is the same input Step 1 produces.
Start the gap assessment