Glossary

A formal, machine-readable inventory of every software component (proprietary, open-source, third-party) that ships in a device. Required by FDA for cyber devices under Section 524B.

An IHE/HIMSS-standardized form (MDS2) that manufacturers provide to healthcare delivery organizations describing the security characteristics of a device.

AAMI Technical Information Report describing security risk management principles for medical devices, the foundation referenced by FDA guidance.

Standard for medical device security risk management activities and documentation, complementary to ISO 14971 safety risk management.

International standard specifying a secure development lifecycle (SDL/SPDF) for health software and health IT systems.

IEC 62304 term for software not developed for a specific medical device (e.g., OS, libraries, OSS). Must be identified, risk-assessed, and tracked for vulnerabilities throughout the product lifecycle.

International standard for medical device software lifecycle processes, covering software safety classification (A/B/C), development, maintenance, risk, and configuration management.

International standard for the application of risk management to medical devices. Security risk management (per AAMI SW96/TIR57) complements but does not replace ISO 14971 safety risk.

International standard for information security management systems (ISMS). Often referenced for the manufacturer's enterprise security posture, distinct from product security.

UL standard series for testable cybersecurity criteria of network-connectable products and systems, including UL 2900-2-1 for healthcare and wellness devices.

A voluntary framework (Identify, Protect, Detect, Respond, Recover, Govern) widely referenced by FDA guidance and used to structure a manufacturer's overall security program.

Regulation (EU) 2017/745 governing medical devices in the European Union. Includes cybersecurity expectations clarified by MDCG 2019-16 guidance.

An EU-designated conformity assessment organization that audits manufacturers and reviews technical documentation for CE marking under MDR/IVDR.

A lifecycle framework (recognized by FDA) for embedding security into design, development, manufacturing, and postmarket. AAMI TIR57 and IEC 81001-5-1 are common reference standards.

A documented policy and process for receiving, triaging, and disclosing security vulnerabilities responsibly. Required for FDA cyber devices.

The internal team responsible for receiving vulnerability reports, coordinating fixes, and communicating with researchers, customers, and regulators. Required in practice to meet FDA CVD expectations.

Goal-oriented security testing that simulates an attacker against a device, its interfaces, and its supporting infrastructure. FDA expects penetration testing evidence for cyber devices.

A hospital, clinic, or health system that deploys and operates medical devices. The primary audience for MDS2 forms and customer-facing security documentation.

The FDA cybersecurity authority for cyber devices. Requires a cybersecurity management plan, SBOM, vulnerability monitoring, and reasonable assurance of security in premarket submissions.

An early FDA review checkpoint. If a 510(k) submission fails the RTA cybersecurity checklist, it is returned without substantive review, restarting the clock.

FDA's interactive PDF template for 510(k) and De Novo submissions. Cybersecurity sections are guided and required.

FDA's framing for managing risk and quality from concept through end-of-support, including postmarket surveillance and security updates.

FDA's most stringent device marketing pathway, used for high-risk Class III devices.

FDA premarket notification establishing substantial equivalence to a predicate device, the most common pathway for moderate-risk devices.

FDA pathway for novel low-to-moderate risk devices that have no predicate.

An FDA-authorized plan that lets a manufacturer pre-specify certain device modifications (often AI/ML or security updates) and implement them post-clearance without a new submission, provided changes stay within the agreed protocol.

FDA's current Good Manufacturing Practice requirements for medical devices, covering design controls, CAPA, document control, and production. Being replaced by QMSR in February 2026.

FDA's updated quality system rule that harmonizes 21 CFR 820 with ISO 13485:2016. Takes effect February 2, 2026, replacing the legacy QSR.

A legally marketed device used as the basis for a 510(k) substantial-equivalence claim. Cybersecurity comparisons to the predicate are increasingly scrutinized by FDA.

The foundational U.S. statute giving FDA authority over food, drugs, and medical devices. Section 524B (added by the 2023 omnibus) created explicit cybersecurity authority for cyber devices.

An emerging extension of the SBOM that catalogs cryptographic primitives, libraries, key sizes, and algorithms used by a device.

A threat modeling taxonomy (Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, Elevation of privilege) widely used for medical device threat models.

Tooling that scans software for known-vulnerable components and license risks, and is the primary mechanism for generating and maintaining an SBOM.

A public catalog of disclosed security vulnerabilities, each assigned a unique CVE ID. Used for tracking known issues against SBOM components.

An open framework for scoring vulnerability severity (0.0–10.0) based on exploitability and impact. FDA expects manufacturers to triage findings using CVSS plus device-specific clinical impact.

A community catalog of software and hardware weakness types (e.g., CWE-79 XSS, CWE-787 out-of-bounds write). Useful in threat modeling and root-cause analysis.

A machine-readable companion to an SBOM that states whether a known vulnerability actually affects a given product (e.g., 'not affected because component is not invoked'). Reduces noise from SBOM scans.

The set of roles, policies, and systems for issuing, managing, and revoking digital certificates. Underpins device identity, signed firmware, and secure communications.

Tamper-resistant hardware that generates, stores, and uses cryptographic keys. Often used in manufacturing to sign firmware and provision device identities.

TLS in which both client and server present and validate certificates. Common pattern for device-to-cloud and device-to-gateway authentication in connected medical devices.

Mechanism for remotely delivering signed firmware or software updates to deployed devices. FDA expects a documented, secure update path for the supported lifetime of the device.

A boot process that cryptographically verifies firmware/software integrity before executing it, anchored in a hardware Root of Trust. Foundational control for tamper resistance.

An immutable hardware or firmware element (e.g., fused public key, secure element) that anchors all higher-level trust decisions like secure boot and attestation.