Why vulnerability management is the engine of a secure-by-design product

Secure by design is a claim with a shelf life

A product is secure by design when security was a first-class input to its architecture — threat modelling, least privilege, a small attack surface, memory-safe choices where they matter. It is secure by default when the out-of-the-box configuration is the safe one, so a customer who changes nothing is still protected. Both are worth doing, and both are genuinely design-time decisions.

The catch is that neither claim survives contact with time on its own. The dependency you audited last year ships a critical CVE this year. The protocol you chose because it was sound turns out to have an implementation flaw. A design that was secure when you shipped it is only secure now if someone is watching what the world learns about it and acting on that. That watching-and-acting loop is vulnerability management.

Where it lives in the secure SDLC

A secure software development lifecycle (Secure SDLC) is the process that turns "we care about security" into repeatable, evidenced activity at every stage — requirements, design, implementation, verification, release, and maintenance. Vulnerability management is the practice that spans the last two and feeds back into all the others.

This is exactly how IEC 62443-4-1 frames it. The standard defines eight practices for a secure development lifecycle, and two of them — Practice 6, management of security-related issues, and Practice 7, security update management — are vulnerability management in all but name. They require a defined way to receive reports, assess and prioritise them, remediate, and get fixes to operators. The standard does not treat this as an afterthought bolted onto development; it treats it as one of the load-bearing practices.

• Receive — a monitored channel for internally found and externally reported weaknesses, including a coordinated disclosure route.
• Assess — triage against an accurate inventory of what you actually ship, so "are we affected?" has a fast, defensible answer.
• Remediate — a path from a confirmed vulnerability to a released fix, with the timeline driven by severity.
• Inform — telling operators what changed and why, which is itself a CRA obligation, not a courtesy.

The CRA turns the practice into a legal duty

The Cyber Resilience Act takes what IEC 62443-4-1 recommends and makes the core of it mandatory for products with digital elements placed on the EU market. Annex I sets out the essential requirements, and its second part is specifically about vulnerability handling: manufacturers must identify and document vulnerabilities (including maintaining a software bill of materials), address them without delay through security updates, apply effective and regular testing, and share information about fixed vulnerabilities once they are available.

On top of the product requirements, the CRA adds reporting duties with hard clocks: an actively exploited vulnerability, and a severe incident, each trigger an early-warning notification to the relevant CSIRT and ENISA within 24 hours. You cannot meet a 24-hour clock with a process you improvise on the day. It presumes a vulnerability-management function that is already running, already knows the product, and already has the channels open.

What a working platform looks like

In practice, keeping these promises at product scale is a tooling problem as much as a process one. The parts that have to exist and stay current: an accurate inventory of components and dependencies (the SBOM), continuous scanning of code and its dependencies, a way to match new CVEs against what you actually ship, a prioritisation model that reflects real exploitability rather than raw CVSS, and an audit trail that can show an assessor when each issue was found, judged, and fixed.

You do not have to build all of that from scratch. Consolidated application-security platforms such as Aikido Security bring dependency and code scanning, SBOM generation, and vulnerability triage into one place, which is often the fastest way to get from an ad-hoc spreadsheet to a defensible, evidenced process. The tool is not the point, though — the process is. A platform makes the loop cheap to run; it does not decide your severity thresholds, your remediation SLAs, or your disclosure policy for you.

The bottom line

Secure by design and secure by default get a product to a strong starting position. Vulnerability management is what keeps it there — and it is the thread that ties an IEC 62443-4-1 process to the CRA obligations you will be measured against. Treat it as core product infrastructure, not a compliance chore, and the compliance follows from the engineering rather than fighting it.