What I keep noticing about secure development: it works when interest meets expertise

A pattern I kept seeing

A secure software development lifecycle (Secure SDLC) is meant to turn "we care about security" into repeatable, evidenced work at every stage — requirements, design, implementation, verification, release, and maintenance. On paper, the teams I worked with had that. In reality, some of those lifecycles were alive and some were just laminated. The difference was never the diagram. It was whether the activities in the diagram had someone behind them who cared.

When I finally sat properly with IEC 62443-4-1, the thing that struck me was the order. The standard lays out eight practices, and it does not open with threat modelling or secure coding — the parts everyone wants to talk about. It opens with Security Management (Practice 1). At first that felt like bureaucracy. Now I read it as the standard putting the same thing first that experience taught me the hard way: sort out the people, and the rest becomes possible. Skip that, and no practice above it ever really takes.

Two requirements inside that first practice are the ones I care about most. SM-2, identification of responsibilities, asks you to name who owns each security activity. SM-4, security expertise, asks you to make sure those people actually have the competence — and to train them toward it if they do not. One names the owner; the other makes the owner real. They sound like admin. They are, in my experience, where the whole thing is decided.

SM-2: the activities nobody owned were the ones that vanished

The clearest thing I ever learned about SM-2 I learned by watching it be ignored. On more than one team, some security activity — dependency triage, a design-review threat model, sign-off on a release — belonged to "the team," which is to say nobody. It did not fail loudly. It simply never happened, month after month, and everyone assumed someone else had it. The gap only surfaced when an auditor asked, or worse, when something got through that a named owner would have caught.

So when SM-2 insists that every security-related activity has an identified owner — a specific role, specific people, not a gesture at the group — I read it as the standard encoding a lesson I had already paid for. Naming an owner is what gives an activity a pulse. It also makes accountability traceable: someone can follow any activity back to the person answerable for it, and the team can see its own gaps before someone outside does. I used to think that was paperwork. It is not. It is the difference between a process that exists and one that merely appears to.

SM-4: but a name on the box was never enough

The other half of the lesson was that assigning an owner achieves nothing if the owner has never been shown how. I watched capable, willing engineers get handed a threat-modelling responsibility with no grounding in it, and produce something that ticked the box and caught nothing — not because they were careless, but because no one had closed the gap between the task and their training. That is precisely what SM-4 is for: assess the security expertise of the people carrying each responsibility, and provide the education that brings them up to the level the role needs, with the whole thing recorded so competence is demonstrated rather than assumed.

Put SM-2 and SM-4 together and you get a loop I wish I had understood earlier: identify the responsibilities, assign them to people, check whether those people are qualified, and train them where they are not. That loop is the human foundation the technical practices sit on. A superb method is worthless in the hands of someone never taught to use it — and SM-4 exists so that gap does not open by accident.

Where it actually worked: interest meeting expertise

Here is the part the standard implies but that I only really learned by watching outcomes diverge. Knowledge and experience are necessary, but on their own they were never what made a team secure. The teams that pulled it off had people at the base who were genuinely interested in security — and, just as much, interested in promoting and controlling it across the team rather than hoarding it. I saw plenty of qualified people treat security as a chore, and their box-ticking protected no one. I saw a few engaged ones quietly raise the standard of everybody around them. The gap between those two outcomes was interest, not credentials.

That is why, when SM-2 asks you to assign responsibilities, I have come to treat it as a hiring-grade decision rather than an org-chart entry. The people who made secure development work were recognisable before you gave them the title: the engineer already asking the awkward questions in design reviews, curious about how things break, willing to hold a line when a deadline leaned on it. Competence paired with that conviction is what turned an assigned responsibility into a practised one. Competence on its own mostly turned into documentation.

• Knowledge and experience — the baseline SM-4 assesses. Necessary, and the easiest of the three to check. Also, on its own, the least predictive of whether things go well.
• Genuine interest — the one I now weight most heavily. It is what carries the work through the long stretch between audits, when no one is watching.
• An instinct to promote and control — the willingness to advocate for secure practice with peers and hold the team to it, instead of owning security alone in a corner.

The security champion: the role where I saw it come together

The place I most often saw responsibility and expertise land in one person was the nominated security champion — embedded in the product team, not parked in a detached central function. When it worked, the champion was SM-2 and SM-4 made flesh: a named owner of security inside the team whose expertise had actually been developed and shown. They were the everyday advocate — facilitating threat models, tending the secure coding standard, being the first point of escalation, bridging the team to the accountable owner above. The teams with a real champion felt different to work in. Security was a conversation, not an inspection.

This is also where I changed my mind about training and certification. I used to be sceptical of certificates. What I came to see is that they do two genuinely useful things for a champion: they give a structured path to the expertise SM-4 asks for, and — this is the part I underrated — they give the person standing. A champion who has earned a recognised secure-development or product-security credential is listened to differently in a design review. The certificate is not the point; the credibility to promote secure practice and the authority to control that it is followed is the point. And usefully, that same certification becomes part of the evidence that SM-4 is satisfied.

What I take from all of it

IEC 62443-4-1 puts Security Management first, and after everything I have watched, I think it is right to. A lifecycle is only ever as sound as the people running it. SM-2 makes you name who owns each activity; SM-4 makes you prove they are equipped. My own version of the same idea is simpler: it worked best when interest and expertise met in the same person, and it worked worst when we had one without the other. Choose people with knowledge, experience, and a real drive to promote and control security; invest in their training; nominate and properly empower champions; and keep that development going. Do that, and the technical practices above finally have something solid to stand on.