Regulated product security lifecycles: IEC 62443-4-1, FDA 524B, ISO/SAE 21434 and UN R155/R156

Each instrument names the same core activities in its own vocabulary. Build the activity once with evidence that names the product version, then map it into each instrument's documents.

IEC 62443-4-1 specifies process requirements for developing and maintaining secure industrial automation and control products: hardware, software or firmware. It applies to the product developer and maintainer, not to the integrator or the asset owner, who have other parts of the 62443 series. Its eight practices are security management, specification of security requirements, secure by design, secure implementation, security verification and validation testing, management of security-related issues, security update management, and security guidelines for users. It also defines four maturity levels, adapted from CMMI, for how consistently the practices are performed.

Certification bodies assess development processes against it, for example under the ISASecure Security Development Lifecycle Assurance (SDLA) scheme and the IECEE scheme. FDA's premarket guidance names ANSI/ISA 62443-4-1 as a framework from another sector that may also comply with the Quality Management System Regulation, and lists IEC 81001-5-1:2021, the health-software security lifecycle standard derived from it, among the medical device frameworks to consider.

Section 524B of the FD&C Act, added by the Food and Drug Omnibus Reform Act of 2022, has applied to premarket submissions such as 510(k), De Novo and PMA since 29 March 2023. A cyber device is one that “(1) includes software validated, installed, or authorized by the sponsor as a device or in a device; (2) has the ability to connect to the internet; and (3) contains any such technological characteristics validated, installed, or authorized by the sponsor that could be vulnerable to cybersecurity threats”. FDA reads the ability to connect to the internet broadly: intentionally or unintentionally, through any means.

For a cyber device the sponsor must submit a plan to monitor, identify and address postmarket vulnerabilities and exploits, including coordinated vulnerability disclosure (524B(b)(1)); processes that give a reasonable assurance the device and related systems are cybersecure, with updates and patches on a reasonably justified regular cycle for known unacceptable vulnerabilities and, as soon as possible out of cycle, for critical vulnerabilities that could cause uncontrolled risks (524B(b)(2)); and an SBOM covering commercial, open-source and off-the-shelf components (524B(b)(3)). FDA's guidance notes that failing to comply with 524B(b)(2) is a prohibited act under section 301(q).

The guidance, reissued on 2 February 2026 to match the Quality Management System Regulation, describes what to submit. It asks for machine-readable SBOMs with the NTIA minimum elements plus, for each component, its level of support and end-of-support date; security architecture views, at least a global system view, a multi-patient harm view, an updatability and patchability view and security use case views; cybersecurity testing with the testers' independence and scope; and a cybersecurity management plan. It says vulnerabilities in CISA's Known Exploited Vulnerabilities catalog should be designed out of the device.

A component that stops being supported before the device does becomes an unpatched component in the field. Record each component's support level and end-of-support date in the SBOM you generate for each release (/domains/supply-chain/sbom/generate-release-inventory/), and compare them with the device's own support end. The example fails on purpose: Mbed TLS 3.6 is a long-term-support branch supported until March 2027, years before this pump's support ends, so the plan has to include a migration, for example to the 4.1 LTS branch, which is supported until March 2029, and onward.

{
  "bomFormat": "CycloneDX",
  "specVersion": "1.6",
  "serialNumber": "urn:uuid:3e671687-395b-41f5-a30f-a58921a69b79",
  "version": 3,
  "metadata": {
    "timestamp": "2026-10-08T14:02:00Z",
    "component": {
      "type": "firmware",
      "name": "pump-controller",
      "version": "2.4.0"
    },
    "properties": [
      {
        "name": "example:device-support-end",
        "value": "2034-12-31"
      }
    ]
  },
  "components": [
    {
      "type": "operating-system",
      "name": "example-rtos",
      "version": "9.2.1",
      "supplier": {
        "name": "Example RTOS Vendor (fictional)"
      },
      "purl": "pkg:generic/example-rtos@9.2.1",
      "properties": [
        {
          "name": "example:support-level",
          "value": "actively maintained"
        },
        {
          "name": "example:end-of-support",
          "value": "2035-06-30"
        }
      ]
    },
    {
      "type": "library",
      "name": "mbedtls",
      "version": "3.6.6",
      "purl": "pkg:github/Mbed-TLS/mbedtls@v3.6.6",
      "properties": [
        {
          "name": "example:support-level",
          "value": "actively maintained"
        },
        {
          "name": "example:end-of-support",
          "value": "2027-03-31"
        }
      ]
    }
  ]
}

It reads the support properties from each component and fails on an unknown level, a component no longer maintained or abandoned, a missing date, or support that ends before the device's. FDA accepts unknown support information only with a justification, so the script lets unknown through for a reviewer to judge. Run it on every release build, together with your SBOM quality checks.

"""Check that every SBOM component states the support information FDA's premarket guidance asks for.

FDA asks, for each component, the level of support from its manufacturer (for example actively
maintained, no longer maintained, abandoned) and its end-of-support date, in the SBOM or in an
addendum. This SBOM carries them as properties in the manufacturer's own "example:" namespace.
Usage: python3 check_component_support.py pump-sbom.cdx.json
"""

import json
import sys
from datetime import date

LEVELS = {"actively maintained", "no longer maintained", "abandoned"}


def props(item):
    return {p["name"]: p["value"] for p in item.get("properties", [])}


with open(sys.argv[1], encoding="utf-8") as f:
    bom = json.load(f)
device_end = date.fromisoformat(props(bom["metadata"])["example:device-support-end"])

problems = []
for c in bom.get("components", []):
    name, p = f"{c['name']}@{c.get('version', '?')}", props(c)
    level, end = p.get("example:support-level"), p.get("example:end-of-support")
    if level not in LEVELS:
        problems.append(f"{name}: support level {level!r} is not one of {sorted(LEVELS)}")
    elif level != "actively maintained":
        problems.append(f"{name}: {level}; assess the risk and plan a replacement")
    if not end:
        problems.append(f"{name}: no end-of-support date (write 'unknown' and justify it)")
    elif end != "unknown" and date.fromisoformat(end) < device_end:
        problems.append(f"{name}: support ends {end}, before the device's {device_end}")

print("\n".join(problems) or "component support information OK")
sys.exit(1 if problems else 0)

UN Regulation No. 155, adopted by the UNECE World Forum WP.29 in June 2020 and in force since 22 January 2021, makes cybersecurity a condition of vehicle type approval in the countries that apply it. The manufacturer needs a certificate of compliance for its cybersecurity management system, which is audited, and a type approval for each vehicle type that shows risks were assessed, including the threats listed in the regulation's Annex 5, and mitigated and tested. Only vehicle manufacturers get the approval, but they must show they manage supply-chain risk, so suppliers receive the requirements through contracts. UN Regulation No. 156 does the same for software updates with a software update management system.

ISO/SAE 21434:2021, Road vehicles: Cybersecurity engineering, is the standard most used to meet R155. Its clauses run from organizational and project cybersecurity management through distributed activities with suppliers, continual activities such as monitoring and vulnerability management, concept, product development, validation, production, operations and maintenance, to end of support and decommissioning; clause 15 describes the methods for threat analysis and risk assessment. The joint ISO and SAE working group is planning a second edition. For R156, the UK Vehicle Certification Agency points to ISO 24089, software update engineering, as the closest standard.

Keep one threat model per product and version, one SBOM per build, one vulnerability intake and one update pipeline that can recover from a failed update (/domains/appsec/platform-security/embedded-update-security/), and record each with the product version it covers. Then produce what each instrument needs from them: the FDA premarket package and labeling, the 62443-4-1 process evidence an assessor samples, the R155 risk assessment and test results for a vehicle type. Don't relabel one document to stand in for another: a 62443 certificate covers your development process, not a device's premarket submission, and a type approval covers a vehicle type, not your other products.

The same shared evidence also answers the EU Cyber Resilience Act's Annex I for products sold in the EU, though the CRA does not apply to products covered by the EU medical device regulations (2017/745 and 2017/746) or the vehicle General Safety Regulation (2019/2144), under its Article 2(2). /frameworks/compliance-evidence-reuse/ shows how to index the evidence so each instrument's mapping points at the same records.

Sources & further reading

The standards, specifications and documentation behind the guidance above. Each is the evidence for a claim on this page; consult it for detail beyond the defaults and versions listed here.

1. IEC 62443-4-1:2018 Secure product development lifecycle requirements (IEC webstore). Edition 1.0 (15 January 2018).
2. FDA guidance: Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions. Final guidance, issued 2 February 2026; docket FDA-2021-D-1158.
3. FDA guidance PDF: sections V to VII and Appendix 2. Issued 2 February 2026; supersedes the edition of 27 June 2025.
4. 21 U.S.C. 360n-2: Ensuring cybersecurity of devices (FD&C Act section 524B). U.S. Code, 2024 edition.
5. Federal Register: Medical Devices; Quality System Regulation Amendments (89 FR 7496, 2 February 2024, via govinfo)
6. ISO/SAE 21434:2021 Road vehicles: Cybersecurity engineering. Edition 1 (August 2021).
7. UN Regulation No 155: cyber security and cyber security management system (EUR-Lex, 2021/387)
8. UN Regulation No 156: software update and software update management system (EUR-Lex, 2021/388)
9. UK Vehicle Certification Agency: cyber security and software updating (UN R155 and R156 dates). Last updated 22 May 2026.
10. Mbed TLS 3.6.0: long-term support branch, supported until at least March 2027
11. Mbed TLS 4.1.0: long-term support branch, supported until at least March 2029. 31 March 2026.

Reference information

Tags

Firmware and hardware securitySecure development lifecycleCompliance and assurance evidenceRegulation

SDLC phase

PlanningSecurity program

Role

AppSec engineersSecurity leaders

Download this guide as Markdown

Continue exploring