100+ definitions across regulation, standards, threat modeling, SBOM, testing, postmarket, AI/ML, EU, and core concepts. Search with autocomplete or filter by term type, standard/reg domain, and related concepts.
Term type
Showing 124 of 124
Per Section 524B, a device that (1) includes software validated/installed/authorized by the sponsor, (2) has the ability to connect to the internet, and (3) contains technological characteristics that could be vulnerable to cybersecurity threats.
Why it matters
If your device meets all three criteria, the full premarket cybersecurity package is mandatory.
The federal statute that gives FDA its authority over food, drugs, devices, and cosmetics in the United States.
Health Insurance Portability and Accountability Act. Sets US privacy and security rules for protected health information (PHI) handled by covered entities and business associates.
Why it matters
Cloud-connected devices that touch PHI may pull manufacturers into HIPAA business-associate obligations.
Protecting and Transforming Cyber Health Care Act - the legislative vehicle that became Section 524B inside the Consolidated Appropriations Act, 2023.
Individually identifiable health information protected under HIPAA.
FDA's modernized 21 CFR Part 820, effective February 2, 2026, which harmonizes US quality system requirements with ISO 13485:2016.
Why it matters
Cybersecurity activities need to be embedded in design controls and risk management under the QMSR framework.
Section of the Federal Food, Drug, and Cosmetic Act added by the Consolidated Appropriations Act of 2023, granting FDA explicit authority to require a complete cybersecurity package in every cyber-device premarket submission.
Why it matters
Cybersecurity is now a federal statutory requirement for premarket submissions - not a best practice. Missing pieces can trigger Refuse To Accept (RTA).
FDA correspondence sent during review listing deficiencies the sponsor must address before clearance. Different from the AI in 'AI/ML'.
Why it matters
Cybersecurity AI-letter responses are often the difference between clearance and a multi-month delay.
FDA's interactive PDF submission template. Mandatory for 510(k) (since Oct 2023) and De Novo (since Oct 1, 2025). Has structured upload slots for the cybersecurity package.
FDA's evolving framework for AI/ML-enabled device software, including Predetermined Change Control Plans (PCCPs) and Good Machine Learning Practices.
FDA guidance on managing cybersecurity vulnerabilities and exploits in marketed and distributed medical devices, including the controlled-vs-uncontrolled risk framework.
FDA's final premarket cybersecurity guidance, effective February 3, 2026. Defines the seven-section cybersecurity submission format reviewers enforce at Technical Screening.
Why it matters
Operationalizes Section 524B. Missing a required section can trigger an RTA before the 180-day clock starts.
FDA's mechanism for getting non-binding written feedback on submission strategy, study design, or specific cybersecurity questions before filing.
Why it matters
A Pre-Sub is the cheapest way to validate a cybersecurity approach before committing to a full submission.
An administrative hold FDA issues when a 510(k) or De Novo submission is missing required elements. The 180-day review clock does not start until RTA is cleared.
Why it matters
Cybersecurity gaps are now a top RTA driver. Most are avoidable with a complete SPDF and threat model.
Submission demonstrating that a device is substantially equivalent to a legally marketed predicate device. Most Class II devices clear via 510(k).
FDA program offering priority review and sprint-style FDA engagement for devices that provide more effective treatment for life-threatening or irreversibly debilitating conditions.
Pathway for novel low-to-moderate-risk devices with no valid predicate. Creates a new classification regulation when granted.
FDA risk-based classification. Class I = low risk (most exempt), Class II = moderate risk (typically 510(k)), Class III = high risk (typically PMA).
Pathway for devices intended to treat or diagnose conditions affecting fewer than 8,000 patients per year in the US.
FDA mechanism allowing an unapproved device to be used in a clinical study to collect safety and effectiveness data.
Type of Q-Submission used to obtain FDA feedback on testing plans, regulatory strategy, or specific cybersecurity questions before filing.
A legally marketed device used as the basis for substantial equivalence in a 510(k) submission.
Most stringent FDA pathway, required for Class III devices. Demands clinical data demonstrating safety and effectiveness.
Software intended to be used for medical purposes that performs those purposes without being part of a hardware medical device.
Software that is integral to or controls a hardware medical device.
Standard for application of quality management system concepts to medical device data systems.
AAMI TIR57:2016 (R2023) - Principles for Medical Device Security – Risk Management. Predecessor and companion to SW96.
AAMI TIR97:2019 - Principles for medical device security – Postmarket risk management for device manufacturers.
ANSI/AAMI SW96:2023 - Standard for Medical Device Security – Security Risk Management. The current consensus standard reviewers expect.
Family of standards covering basic safety and essential performance of medical electrical equipment.
International standard for medical device software lifecycle processes. Defines software safety classes A, B, and C.
International standard for security activities in the health software lifecycle. The cybersecurity counterpart to IEC 62304.
International QMS standard for medical device manufacturers. The QMSR (effective Feb 2, 2026) harmonizes 21 CFR Part 820 with ISO 13485:2016.
International standard for risk management of medical devices. The framework cybersecurity risk management plugs into.
International standard for an information security management system (ISMS). Common for the manufacturer's enterprise side.
Voluntary risk-based framework organized around six functions (Govern, Identify, Protect, Detect, Respond, Recover).
Guide for conducting risk assessments. Useful baseline for IT-side risk methodology, complementary to AAMI SW96 on the device side.
Catalog of security and privacy controls for federal information systems. Often referenced for cloud-connected device backends.
UL standards for software cybersecurity for network-connectable products, including UL 2900-2-1 specific to medical devices.
Sum of all points where an unauthorized user can attempt to enter, extract data from, or interact with a device or system.
Tree-structured diagram of how an attacker might achieve a specific goal, with nodes representing attack steps or sub-goals.
FDA postmarket framework distinguishing 'controlled' (acceptable residual) from 'uncontrolled' risk. Uncontrolled risk requiring action triggers reporting and remediation timelines.
Diagram showing how data moves through a system, including processes, data stores, external entities, and trust boundaries.
Legacy threat-rating method (Damage, Reproducibility, Exploitability, Affected users, Discoverability). Largely superseded by CVSS for scoring.
Globally accessible knowledge base of adversary tactics, techniques, and procedures (TTPs). Useful for threat modeling and detection engineering.
Common Attack Pattern Enumeration and Classification - catalog of common attack patterns used to model threats.
Common Weakness Enumeration - community-developed list of common software and hardware weakness types.
Process for Attack Simulation and Threat Analysis - risk-centric, seven-stage threat modeling methodology.
Discipline of tracing each cybersecurity threat to a possible patient-safety consequence - the bridge between cyber risk and ISO 14971 risk.
Lifecycle process for designing, building, and maintaining secure products. Required as a documented framework in FDA premarket submissions.
Threat categorization framework: Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, Elevation of privilege.
Structured analysis of a system identifying assets, trust boundaries, threats, and mitigations. Required artifact in FDA premarket submissions.
Line in a system architecture across which the level of trust changes. Common locations for security controls and threat enumeration.
NIST identifier scheme for IT products and platforms. Used to map components to vulnerabilities in the NVD.
OWASP-maintained SBOM standard widely used in MedTech. Supports SBOM, VEX, and machine-learning bill of materials.
NTIA-defined baseline data fields for any SBOM: supplier, component name, version, unique identifier, dependency relationship, author, and timestamp.
Standardized URL format for identifying software packages across ecosystems (npm, PyPI, Maven, etc.). Common identifier in SBOMs.
Machine-readable inventory of software components, dependencies, and metadata used in a product. Required for cyber-device premarket submissions.
ISO/IEC 19770-2 tags identifying installed software. One of the SBOM-compatible identifier formats.
ISO/IEC 5962 SBOM specification maintained by the Linux Foundation.
Discipline of identifying, assessing, and mitigating risks from third-party software, firmware, hardware, and services in the device supply chain.
Off-the-shelf software, firmware, or hardware integrated into the device that the manufacturer did not author. Subject to FDA documentation expectations.
Companion artifact to an SBOM that states whether known vulnerabilities are actually exploitable in the product (status: not_affected, affected, fixed, under_investigation).
Security testing focused on inputs and behaviors at the edges of valid input ranges, often combined with fuzzing.
Testing of a running application by sending crafted inputs to find runtime vulnerabilities.
Automated testing technique that supplies malformed or unexpected inputs to find crashes, hangs, or memory-safety bugs. Expected for protocol parsers and exposed interfaces.
Authorized simulated attack on a device or system to find exploitable vulnerabilities. Required testing artifact in FDA cybersecurity submissions.
Goal-based adversary simulation across people, process, and technology - broader in scope than a scoped penetration test.
Manual or tool-assisted review of source code focused on security defects - auth flaws, crypto misuse, input validation, memory safety.
Automated identification of open-source and third-party components and their known vulnerabilities. Inputs into SBOM and VEX.
Analysis of source code or binaries without executing them, to identify security defects.
Systematic identification of known vulnerabilities (typically via automated scanners) without active exploitation.
OASIS standard for machine-readable security advisories. Increasingly expected for postmarket disclosures.
Process by which manufacturers receive, triage, remediate, and disclose vulnerabilities reported by external researchers.
Why it matters
FDA expects every cyber-device manufacturer to have a published CVD policy.
Defined points at which a manufacturer stops shipping (EOL) or supporting (EOS) a product. Cybersecurity expectations include planning and customer notification well before EOS.
Coordinated process to detect, contain, eradicate, and recover from a cybersecurity incident.
International standard for vulnerability disclosure processes.
International standard for vulnerability handling processes inside an organization.
Process for identifying, testing, releasing, and tracking software updates to remediate vulnerabilities and bugs over a device's supported life.
Documented plan describing how the manufacturer monitors for new vulnerabilities and threats affecting marketed devices, and how decisions get made.
Team responsible for receiving, triaging, and responding to security issues affecting an organization's products.
Crafted input designed to cause an ML model to misclassify or behave incorrectly while appearing normal to humans.
Set of guiding principles for the development of AI/ML medical devices, jointly published by FDA, Health Canada, and the UK MHRA.
Inventory of model artifacts, datasets, and dependencies - a CycloneDX extension applicable to AI/ML medical devices.
Degradation of model performance over time as real-world data diverges from training data. A key postmarket monitoring concern for AI/ML devices.
Attack in which an adversary injects malicious data into model training to degrade accuracy or insert backdoors.
FDA mechanism allowing pre-authorized modifications to AI/ML devices without a new submission, provided the changes follow the documented plan.
Conformity marking required for devices placed on the EU market under MDR/IVDR.
EU regulation imposing cybersecurity requirements on products with digital elements. Medical devices are largely carved out, but the interaction with MDR matters.
Regulation (EU) 2017/746 governing in vitro diagnostic devices in the EU.
Regulation (EU) 2017/745 governing medical devices placed on the EU market. Annex I, Section 17 contains the IT security and software requirements.
Canadian medical-device regulator. Publishes premarket cybersecurity guidance broadly aligned with FDA.
International Medical Device Regulators Forum. Publishes harmonized guidance, including 'Principles and Practices for Medical Device Cybersecurity'.
Medical Device Coordination Group guidance on cybersecurity for medical devices under the EU MDR/IVDR.
EU directive on measures for a high common level of cybersecurity across the Union. Touches healthcare operators that may use medical devices.
Pharmaceuticals and Medical Devices Agency - Japanese regulator with cybersecurity expectations referencing IMDRF guidance.
Therapeutic Goods Administration - Australian medical-device regulator. Has its own cybersecurity guidance.
United Kingdom Conformity Assessed marking - UK equivalent of CE marking for the GB market.
Cryptographic signature applied to firmware or software so that a device or system can verify authenticity and integrity before installation.
US federal standards for cryptographic modules. Often referenced for cloud-connected device backends.
Tamper-resistant hardware element (TPM, secure element, HSM) that provides the foundation for secure boot, attestation, and key storage.
Lifecycle of cryptographic keys: generation, distribution, storage, rotation, revocation, and destruction.
Authentication that requires two or more independent factors (something you know, have, or are).
TLS variant requiring both client and server to present X.509 certificates. Common for device-to-cloud authentication.
Cryptographic algorithms resistant to attack by large-scale quantum computers. NIST has standardized initial PQC algorithms; long-lived devices need a migration plan.
System of certificate authorities, certificates, and revocation that binds public keys to identities.
Boot process that cryptographically verifies firmware/software signatures before execution, establishing a root of trust.
Cryptographic protocol providing confidentiality and integrity for network communications. TLS 1.2+ is the floor for medical device cloud links.
Standardized identifier for publicly known cybersecurity vulnerabilities. Issued by CVE Numbering Authorities (CNAs).
Open framework for scoring vulnerability severity (Base, Temporal, Environmental). FDA expects CVSS scoring for vulnerabilities, plus medical-device context.
Unintended communication path that allows information to move in violation of policy or controls.
Layered security strategy in which multiple controls protect against a given threat so that failure of one does not compromise the system.
IEC 60601 concept identifying device performance whose loss or degradation beyond a defined limit results in unacceptable risk.
Data-driven estimate of the probability that a CVE will be exploited in the wild within the next 30 days.
CISA-maintained catalog of vulnerabilities known to be actively exploited. Useful prioritization input for postmarket monitoring.
Principle that every component, user, and process should operate with the minimum permissions necessary.
Property of code that prevents access to memory in unintended ways. Lack of memory safety is the root cause of a large share of CVEs.
NIST-maintained database that enriches CVE entries with CVSS scores, CWE mappings, and CPE identifiers.
Industry-standard list of the most critical web application security risks. The Mobile and API Top 10 lists are also frequently cited.
CISA-promoted principle that security must be a foundational property - designed in from the start rather than bolted on.
Language- and platform-specific guidance (e.g., CERT C, MISRA) for writing software that resists common security defects.
NIST SP 800-218 - set of practices for integrating security into the software development lifecycle. Maps cleanly to FDA SPDF expectations.
Attack that exploits indirect physical or behavioral characteristics (timing, power, EM emissions) to extract secrets.
Security model that assumes no implicit trust based on network location. Every request is authenticated, authorized, and continuously validated.
30-minute strategy session. No cost, no commitment - just answers from people who've shipped 250+ submissions.
