One unified reference for medical-device teams: the formal standards & regulations reviewers cite (FDA Section 524B, AAMI SW96/TIR57, ISO 13485/14971, IEC 62304/81001-5-1, NIST CSF, eSTAR, SBOM, SPDF) merged with the cyber-scoped concepts and long-tail terms that surround them. Use the Scope chips below to focus on standards-only or concepts-only - broader non-cyber medtech terminology cross-links out to MedTechTerms.com.
Scope: this glossary covers the cybersecurity surface of medical-device development - what FDA, AAMI, ISO/IEC, NIST, CISA, and EU MDR expect. For non-cyber medtech terminology (quality systems, clinical, biocompatibility, regulatory pathways), every applicable entry below links out to MedTechTerms.com.
Quick category jumps
Scope
Standards & Regulations covers the named statutes, FDA guidance, and consensus standards (Section 524B, AAMI SW96/TIR57, ISO 13485/14971, IEC 62304/81001-5-1, NIST CSF, SBOM, SPDF, eSTAR). Cyber Concepts & Long-tail covers everything else - threat modeling techniques, SBOM formats, AI/ML cyber, postmarket vuln workflows, etc.
Term type
Showing 86 of 86
Definition
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.
Related & references
Authoritative sources
Definition
The federal statute that gives FDA its authority over food, drugs, devices, and cosmetics in the United States.
Why it matters
Every FDA cybersecurity authority - from premarket review to recalls to Section 524B itself - traces back to this statute. If a regulator can act on your device, the FD&C Act is why.
Related & references
Authoritative sources
Definition
Protecting and Transforming Cyber Health Care Act - the legislative vehicle that became Section 524B inside the Consolidated Appropriations Act, 2023.
Why it matters
The PATCH Act is the legislative origin story for today's mandatory premarket cybersecurity package. Knowing the chain (PATCH Act, Consolidated Appropriations Act 2023, Section 524B) is how you defend a submission timeline against 'is this even required?' pushback.
Related & references
Authoritative sources
Definition
Individually identifiable health information protected under HIPAA.
Why it matters
Any cyber device that processes PHI inherits HIPAA Security Rule obligations on top of FDA cybersecurity expectations. Threat models and pen tests should explicitly call out PHI exposure paths so reviewers see the dual compliance posture.
Related & references
Authoritative sources
Definition
Added by the Consolidated Appropriations Act, 2023, Section 524B gives the FDA explicit authority to require a complete cybersecurity package in every premarket submission for a cyber device, and to refuse submissions that lack one.
Why it matters
Cybersecurity is no longer a 'best practice' - it is a federal statutory requirement. Executive teams are accountable for cybersecurity attestation in the same way they are for clinical and manufacturing risk.
Related & references
Definition
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.
Related & references
Authoritative sources
Definition
FDA's evolving framework for AI/ML-enabled device software, including Predetermined Change Control Plans (PCCPs) and Good Machine Learning Practices.
Why it matters
AI/ML devices add model integrity, training-data confidentiality, and adversarial robustness to the threat model. PCCPs let you ship model updates without re-submitting - but only if the cybersecurity controls were specified up front.
Related & references
Authoritative sources
Definition
The FDA's interactive PDF that has replaced the legacy 510(k) format. The cybersecurity section has structured upload slots for the threat model, SBOM, SPDF documentation, pen test, postmarket plan, and labeling.
Why it matters
Mismatches between checkboxes and uploaded documents trigger early Technical Screening holds. Reviewers are pattern-matchers - the package needs to land in exactly the slots eSTAR expects.
Related & references
Authoritative sources
Definition
FDA guidance on managing cybersecurity vulnerabilities and exploits in marketed and distributed medical devices, including the controlled-vs-uncontrolled risk framework.
Why it matters
Defines the controlled-vs-uncontrolled risk framework that determines whether a vulnerability requires a 30-day MDR-style report or routine remediation. Misclassifying a vulnerability is one of the fastest ways to draw a Warning Letter.
Related & references
Authoritative sources
Definition
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.
Related & references
Authoritative sources
Definition
Standard for application of quality management system concepts to medical device data systems.
Why it matters
Relevant when your device exports data to a cloud backend, EHR, or analytics layer. SW87 helps draw the line between regulated device data and IT-system data so cybersecurity scope stays defensible.
Related & references
Authoritative sources
Definition
The MedTech-specific extension of ISO 14971 for cybersecurity. Defines how to identify cybersecurity assets, threats, and vulnerabilities, then estimate, evaluate, and control the resulting risk.
Why it matters
Many active programs were built against TIR57. The FDA still accepts TIR57-structured risk files, but new programs should follow SW96 going forward.
Related & references
Authoritative sources
Definition
AAMI TIR97:2019 - Principles for medical device security – Postmarket risk management for device manufacturers.
Why it matters
TIR97 is the playbook for the postmarket evidence trail FDA inspects: CVE triage cadence, VEX statements, patch deployment records. Citing it in your postmarket plan signals to reviewers you know the postmarket bar.
Related & references
Authoritative sources
Definition
The current consensus standard for medical device security risk management. Builds on AAMI TIR57 and aligns with the ISO 14971 risk-management process, but treats cybersecurity threats as a first-class risk source.
Why it matters
FDA reviewers expect a Cybersecurity Risk Assessment that follows SW96 (or TIR57) structure. It is the document that ties threats to mitigations to verification evidence in a way regulators recognize.
Related & references
Authoritative sources
Definition
Family of standards covering basic safety and essential performance of medical electrical equipment.
Why it matters
60601 reviewers increasingly ask how cybersecurity failures could compromise essential performance. A weak link between your security risk file and 60601 essential performance analysis is a common deficiency-letter trigger.
Related & references
Authoritative sources
Definition
Defines software safety classification (Class A/B/C), software development planning, requirements, architecture, unit and integration testing, and problem resolution. The bedrock of MedTech software engineering.
Why it matters
62304 evidence is what makes your SBOM and your SPDF defensible. If software lifecycle documentation is thin, the cybersecurity sections built on top of it will not hold up under review.
Related & references
Authoritative sources
Definition
The international standard the FDA points to for the Secure Product Development Framework (SPDF). Defines security activities at each lifecycle stage - planning, requirements, design, implementation, V&V, release, and post-market.
Why it matters
When the FDA asks for SPDF evidence, 81001-5-1 is the most credible structure to organize that evidence around. It maps cleanly to the eSTAR cybersecurity section.
Related & references
Authoritative sources
Definition
The international QMS standard for MedTech. Covers design controls, document control, CAPA, supplier management, and post-market surveillance. The QMSR final rule (effective Feb 2, 2026) harmonizes 21 CFR Part 820 with ISO 13485.
Why it matters
Cybersecurity activities - threat modeling, SBOM upkeep, vulnerability management - have to live inside your QMS. Reviewers will ask which procedure governs each one.
Related & references
Authoritative sources
Definition
The umbrella risk-management standard for medical devices. Defines hazard identification, risk estimation, risk evaluation, risk control, and residual risk evaluation. Cybersecurity risks must be reconciled here so a security control never silently introduces a safety hazard.
Why it matters
Patient safety always wins over a hardening preference. ISO 14971 is the framework that forces that trade-off to be documented. SW96/TIR57 cybersecurity risk decisions feed back into the 14971 file.
Related & references
Authoritative sources
Definition
Six functions: Govern, Identify, Protect, Detect, Respond, Recover. Not MedTech-specific, but commonly used by health-system customers as their procurement bar - so device makers need to map their controls to it.
Why it matters
Hospital security teams will benchmark your device against NIST CSF during procurement. A clear mapping accelerates sales and shortens RFP cycles.
Related & references
Authoritative sources
Definition
Guide for conducting risk assessments. Useful baseline for IT-side risk methodology, complementary to AAMI SW96 on the device side.
Why it matters
Use 800-30 for the cloud/IT pieces of your system risk assessment, and SW96 for the device. Reviewers like seeing both methodologies named explicitly in the cybersecurity risk management plan.
Related & references
Authoritative sources
Definition
UL standards for software cybersecurity for network-connectable products, including UL 2900-2-1 specific to medical devices.
Why it matters
Some hospital procurement teams and EU notified bodies still ask for UL 2900-2-1 alignment as third-party validation. Less weight with FDA today, but useful as supporting evidence in tender responses.
Related & references
Authoritative sources
Definition
Sum of all points where an unauthorized user can attempt to enter, extract data from, or interact with a device or system.
Why it matters
Reviewers expect a documented inventory of every entry point - physical ports, wireless, APIs, update channels, debug interfaces. Undocumented surfaces become deficiencies.
Related & references
Authoritative sources
Definition
Tree-structured diagram of how an attacker might achieve a specific goal, with nodes representing attack steps or sub-goals.
Why it matters
Especially useful for high-risk pathways like firmware update or remote control. Reviewers expect attack trees on Class III and life-supporting devices.
Related & references
Authoritative sources
Definition
FDA postmarket framework distinguishing 'controlled' (acceptable residual) from 'uncontrolled' risk. Uncontrolled risk requiring action triggers reporting and remediation timelines.
Why it matters
FDA's 2026 guidance is explicit: cybersecurity risks are evaluated as uncontrolled until proven otherwise. The submission must show how each one was driven down to acceptable.
Related & references
Authoritative sources
Definition
Diagram showing how data moves through a system, including processes, data stores, external entities, and trust boundaries.
Why it matters
FDA explicitly asks for global system and multi-patient harm DFDs in cyber submissions. Without one, threat modeling is rejected as incomplete.
Related & references
Authoritative sources
Definition
Legacy threat-rating method (Damage, Reproducibility, Exploitability, Affected users, Discoverability). Largely superseded by CVSS for scoring.
Why it matters
Useful for prioritizing within a STRIDE model, but DREAD alone won't satisfy FDA - they expect risk scoring tied back to patient harm via ISO 14971, not just attacker-effort math.
Related & references
Authoritative sources
Definition
Globally accessible knowledge base of adversary tactics, techniques, and procedures (TTPs). Useful for threat modeling and detection engineering.
Why it matters
Pairs with STRIDE to ground threat modeling in real adversary behavior. Submissions that cite ATT&CK techniques read as more mature to FDA reviewers.
Related & references
Authoritative sources
Definition
Common Attack Pattern Enumeration and Classification - catalog of common attack patterns used to model threats.
Why it matters
CAPEC patterns make abstract STRIDE threats concrete and testable. Helpful for traceability between threat → test case → mitigation.
Related & references
Authoritative sources
Definition
Common Weakness Enumeration - community-developed list of common software and hardware weakness types.
Why it matters
Tying findings to CWEs lets you map root causes across SAST, DAST, and pen test reports - and gives reviewers confidence your remediation isn't ad hoc.
Related & references
Authoritative sources
Definition
Process for Attack Simulation and Threat Analysis - risk-centric, seven-stage threat modeling methodology.
Why it matters
Stronger than STRIDE for business-context-heavy devices like SaMD platforms, but you'll still need to map results into the FDA's premarket cybersecurity submission format.
Related & references
Authoritative sources
Definition
Discipline of tracing each cybersecurity threat to a possible patient-safety consequence - the bridge between cyber risk and ISO 14971 risk.
Why it matters
Cybersecurity risk that can't be linked to patient harm gets ignored by reviewers. The whole point of medical-device threat modeling is that traceability - exploit → safety hazard → harm.
Related & references
Authoritative sources
Definition
Line in a system architecture across which the level of trust changes. Common locations for security controls and threat enumeration.
Why it matters
Where the threat model lives or dies - every trust boundary crossing should map to an authentication, authorization, and integrity control. Missing boundaries are the most common deficiency.
Related & references
Authoritative sources
Definition
NIST identifier scheme for IT products and platforms. Used to map components to vulnerabilities in the NVD.
Why it matters
Pair with purl for full vulnerability matching coverage. CPE is older and noisier but still essential for OS- and firmware-level component identification.
Related & references
Authoritative sources
Definition
NTIA-defined baseline data fields for any SBOM: supplier, component name, version, unique identifier, dependency relationship, author, and timestamp.
Why it matters
FDA defers to NTIA's minimum elements as the SBOM acceptance bar. SBOMs missing supplier name, component name, version, or unique identifier are routinely rejected.
Related & references
Authoritative sources
Definition
Standardized URL format for identifying software packages across ecosystems (npm, PyPI, Maven, etc.). Common identifier in SBOMs.
Why it matters
Without purl or CPE, your SBOM components can't be reliably matched to NVD vulnerability data - meaning your monitoring system will miss real CVEs and surface false positives.
Related & references
Authoritative sources
Definition
ISO/IEC 19770-2 tags identifying installed software. One of the SBOM-compatible identifier formats.
Why it matters
Less common than purl/CPE in MedTech but useful for tracking installed software inventories on customer-side gateways and workstations.
Related & references
Authoritative sources
Definition
Discipline of identifying, assessing, and mitigating risks from third-party software, firmware, hardware, and services in the device supply chain.
Why it matters
FDA expects you to manage cyber risk from suppliers and OTS components - not just your own code. Submissions without a supplier risk process get postmarket-related deficiencies.
Related & references
Authoritative sources
Definition
Off-the-shelf software, firmware, or hardware integrated into the device that the manufacturer did not author. Subject to FDA documentation expectations.
Why it matters
OTS components are the source of most CVEs in medical devices. Reviewers want to see how you evaluate, monitor, and patch them across the lifecycle, not just at submission.
Related & references
Authoritative sources
Definition
Security testing focused on inputs and behaviors at the edges of valid input ranges, often combined with fuzzing.
Why it matters
Critical for medical devices that parse external data - boundary defects are where buffer overflows, parser bugs, and protocol confusion attacks live. FDA expects evidence of boundary testing on all external interfaces.
Related & references
Authoritative sources
Definition
Testing of a running application by sending crafted inputs to find runtime vulnerabilities.
Why it matters
DAST proves your running application behaves securely, not just that the code looks safe. Pair with SAST to satisfy reviewers asking for both white-box and black-box evidence.
Related & references
Authoritative sources
Definition
Automated testing technique that supplies malformed or unexpected inputs to find crashes, hangs, or memory-safety bugs. Expected for protocol parsers and exposed interfaces.
Why it matters
FDA increasingly expects fuzzing on protocol parsers and update mechanisms. Submissions that omit fuzz testing for HL7, DICOM, or BLE attack surfaces draw deficiencies.
Related & references
Authoritative sources
Definition
Authorized simulated attack on a device or system to find exploitable vulnerabilities. Required testing artifact in FDA cybersecurity submissions.
Why it matters
Required evidence in every FDA premarket cybersecurity submission. Reviewers reject pen tests that look like vulnerability scans - they expect manual exploitation tied to threat model assumptions.
Related & references
Definition
Goal-based adversary simulation across people, process, and technology - broader in scope than a scoped penetration test.
Why it matters
Optional for most submissions but invaluable for Class III, life-supporting, and platform-style devices. A red team finding shifts your maturity narrative from 'we tested' to 'we were tested.'
Related & references
Authoritative sources
Definition
Manual or tool-assisted review of source code focused on security defects - auth flaws, crypto misuse, input validation, memory safety.
Why it matters
Manual code review still finds defects that SAST and DAST miss - especially logic bugs in authentication, authorization, and crypto. IEC 81001-5-1 expects evidence of it on safety-critical modules.
Related & references
Authoritative sources
Definition
Automated identification of open-source and third-party components and their known vulnerabilities. Inputs into SBOM and VEX.
Why it matters
SCA is how SBOM accuracy actually gets enforced in your pipeline. Without it, your SBOM is a snapshot that's stale by the time it reaches FDA.
Related & references
Authoritative sources
Definition
Analysis of source code or binaries without executing them, to identify security defects.
Why it matters
SAST is table-stakes evidence for IEC 62304 and IEC 81001-5-1. Reviewers want to see the tool, the rule set, and how findings were dispositioned - not just a summary report.
Related & references
Authoritative sources
Definition
Systematic identification of known vulnerabilities (typically via automated scanners) without active exploitation.
Why it matters
Necessary but not sufficient for FDA. A vuln assessment proves coverage; a penetration test proves exploitability. The submission needs both.
Related & references
Authoritative sources
Definition
OASIS standard for machine-readable security advisories. Increasingly expected for postmarket disclosures.
Why it matters
The successor to plain-text security advisories - CSAF lets hospitals and SOCs ingest your VEX and advisories machine-readably. Expected by HSCC and increasingly by FDA reviewers.
Related & references
Authoritative sources
Definition
Defined points at which a manufacturer stops shipping (EOL) or supporting (EOS) a product. Cybersecurity expectations include planning and customer notification well before EOS.
Why it matters
Devices left in service past EOS without a documented support plan are an FDA postmarket cyber risk. Communicate EOL/EOS in writing to customers - silence creates liability.
Related & references
Authoritative sources
Definition
Coordinated process to detect, contain, eradicate, and recover from a cybersecurity incident.
Why it matters
Required postmarket capability under FDA guidance and Section 524B. Reviewers want a documented IR plan, named roles, and evidence the plan is exercised - not just on paper.
Related & references
Authoritative sources
Definition
International standard for vulnerability disclosure processes.
Why it matters
FDA's 2026 guidance and the HSCC JSP both reference 29147 as the standard for vulnerability disclosure. Without a 29147-aligned process, your CVD section is incomplete.
Related & references
Authoritative sources
Definition
International standard for vulnerability handling processes inside an organization.
Why it matters
If 29147 is the front door for incoming reports, 30111 is what happens after. Reviewers ask for both - disclosure intake AND remediation handling.
Related & references
Authoritative sources
Definition
Process for identifying, testing, releasing, and tracking software updates to remediate vulnerabilities and bugs over a device's supported life.
Why it matters
FDA's postmarket guidance evaluates whether your patch cadence matches the risk. 'We can't patch in the field' is no longer an acceptable answer for connected devices.
Related & references
Authoritative sources
Definition
Documented plan describing how the manufacturer monitors for new vulnerabilities and threats affecting marketed devices, and how decisions get made.
Why it matters
FDA expects a documented monitoring plan in every premarket cyber submission for cyber devices. The plan must show how you'll find new vulnerabilities, evaluate them, and respond within stated timelines.
Related & references
Authoritative sources
Definition
Team responsible for receiving, triaging, and responding to security issues affecting an organization's products.
Why it matters
FDA increasingly expects a named PSIRT (or equivalent function) in postmarket submissions. Without one, you can't credibly commit to the response timelines reviewers want to see.
Related & references
Authoritative sources
Definition
Crafted input designed to cause an ML model to misclassify or behave incorrectly while appearing normal to humans.
Why it matters
Required threat for any AI/ML SaMD, especially imaging classifiers. Submissions without adversarial robustness testing draw deficiencies on the algorithm change protocol.
Related & references
Authoritative sources
Definition
Inventory of model artifacts, datasets, and dependencies - a CycloneDX extension applicable to AI/ML medical devices.
Why it matters
Standard SBOM doesn't cover models, datasets, or training pipelines. ML-BOM extensions are emerging and will become expected as FDA's AI/ML guidance matures.
Related & references
Authoritative sources
Definition
Degradation of model performance over time as real-world data diverges from training data. A key postmarket monitoring concern for AI/ML devices.
Why it matters
Drift is a postmarket cybersecurity AND clinical performance issue. FDA expects monitoring with defined triggers for retraining or field action.
Related & references
Authoritative sources
Definition
Attack in which an adversary injects malicious data into model training to degrade accuracy or insert backdoors.
Why it matters
Threat-model AI/ML pipelines explicitly for poisoning - especially federated and continuously-learning models. FDA reviewers are starting to ask about training data provenance and integrity controls.
Related & references
Authoritative sources
Definition
EU regulation imposing cybersecurity requirements on products with digital elements. Medical devices are largely carved out, but the interaction with MDR matters.
Why it matters
CRA applies to most connected products sold in the EU, including a large slice of medical devices. Even MDR-certified devices may need additional CRA conformity work for embedded software components.
Related & references
Authoritative sources
Definition
Canadian medical-device regulator. Publishes premarket cybersecurity guidance broadly aligned with FDA.
Why it matters
Health Canada's cyber expectations are aligned with FDA but with Canadian-specific privacy overlays (PHIPA, PIPEDA). Most FDA-ready packages need only minor adjustments.
Related & references
Authoritative sources
Definition
Medical Device Coordination Group guidance on cybersecurity for medical devices under the EU MDR/IVDR.
Why it matters
The de facto cybersecurity bible for EU medical devices. Notified Bodies use it the way FDA reviewers use the 2026 guidance - gaps mean review delay or refusal.
Related & references
Authoritative sources
Definition
EU directive on measures for a high common level of cybersecurity across the Union. Touches healthcare operators that may use medical devices.
Why it matters
NIS2 doesn't regulate device makers directly but does regulate hospitals and operators. They will push NIS2 controls down to vendors via procurement contracts.
Related & references
Authoritative sources
Definition
Cryptographic signature applied to firmware or software so that a device or system can verify authenticity and integrity before installation.
Why it matters
Required by FDA's 2026 guidance for any device that accepts software updates in the field. Unsigned updates are an automatic deficiency.
Related & references
Authoritative sources
Definition
US federal standards for cryptographic modules. Often referenced for cloud-connected device backends.
Why it matters
FIPS 140-validated modules dramatically simplify your crypto evidence story. They're not legally required for FDA but routinely expected by hospital procurement and federal customers.
Related & references
Authoritative sources
Definition
Tamper-resistant hardware element (TPM, secure element, HSM) that provides the foundation for secure boot, attestation, and key storage.
Why it matters
A hardware root of trust anchors secure boot, code signing, and key storage. Software-only roots of trust are increasingly rejected by reviewers as the threat landscape moves down-stack.
Related & references
Authoritative sources
Definition
Lifecycle of cryptographic keys: generation, distribution, storage, rotation, revocation, and destruction.
Why it matters
Most crypto failures aren't algorithm failures - they're key management failures. FDA reviewers ask how keys are generated, stored, rotated, and destroyed across the device lifecycle.
Related & references
Authoritative sources
Definition
Authentication that requires two or more independent factors (something you know, have, or are).
Why it matters
Required for any administrative or maintenance interface on a connected medical device. Single-factor admin access on a network-attached device is a near-automatic deficiency.
Related & references
Authoritative sources
Definition
TLS variant requiring both client and server to present X.509 certificates. Common for device-to-cloud authentication.
Why it matters
Strong mitigation for cloud-to-device and device-to-device authentication. FDA reviewers like seeing mTLS on backend connections - it answers the 'how do you prevent impersonation' question cleanly.
Related & references
Authoritative sources
Definition
Cryptographic algorithms resistant to attack by large-scale quantum computers. NIST has standardized initial PQC algorithms; long-lived devices need a migration plan.
Why it matters
FDA expects you to track NIST PQC migration plans, especially for long-lived implants. 'Our device will outlive RSA' is now a documented postmarket cyber risk.
Related & references
Authoritative sources
Definition
System of certificate authorities, certificates, and revocation that binds public keys to identities.
Why it matters
Behind every secure-boot, code-signing, and mTLS implementation is a PKI design. Reviewers ask how you provision, rotate, and revoke certificates over the device lifecycle.
Related & references
Authoritative sources
Definition
Cryptographic protocol providing confidentiality and integrity for network communications. TLS 1.2+ is the floor for medical device cloud links.
Why it matters
TLS configuration is one of the easiest pen-test findings to draw - outdated versions, weak ciphers, or self-signed certs. Required posture for any device that touches a network.
Related & references
Authoritative sources
Definition
Unintended communication path that allows information to move in violation of policy or controls.
Why it matters
An advanced threat-model concern, but real on devices that exfiltrate or receive data through unintended channels (timing, DNS, ICMP). Worth modeling on Class III and connected implants.
Related & references
Authoritative sources
Definition
Layered security strategy in which multiple controls protect against a given threat so that failure of one does not compromise the system.
Why it matters
FDA explicitly expects layered controls. A submission with single points of failure (one auth, one boundary, one crypto control) reads as immature regardless of how strong each layer is.
Related & references
Authoritative sources
Definition
Data-driven estimate of the probability that a CVE will be exploited in the wild within the next 30 days.
Why it matters
EPSS exploit-likelihood scoring helps prioritize patching beyond raw CVSS. Mature postmarket programs use EPSS + KEV to defend prioritization decisions to FDA.
Related & references
Authoritative sources
Definition
CISA-maintained catalog of vulnerabilities known to be actively exploited. Useful prioritization input for postmarket monitoring.
Why it matters
CISA's KEV catalog is the fastest-moving signal of vulnerabilities being actively exploited. FDA increasingly expects accelerated response when a KEV-listed CVE hits your SBOM.
Related & references
Authoritative sources
Definition
Principle that every component, user, and process should operate with the minimum permissions necessary.
Why it matters
Reviewers look for least-privilege on user accounts, service accounts, and process privileges. Devices running everything as root or with shared admin accounts draw immediate deficiencies.
Related & references
Authoritative sources
Definition
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.
Why it matters
C/C++ firmware is the source of most memory safety bugs in medical devices. Migrating safety-critical paths to memory-safe languages (Rust, etc.) is increasingly viewed as a cybersecurity risk control.
Related & references
Authoritative sources
Definition
NIST-maintained database that enriches CVE entries with CVSS scores, CWE mappings, and CPE identifiers.
Why it matters
Primary CVE data source for SBOM vulnerability matching. Recent NVD enrichment delays mean you should pair it with secondary sources (GitHub Advisories, OSV) for full coverage.
Related & references
Authoritative sources
Definition
Industry-standard list of the most critical web application security risks. The Mobile and API Top 10 lists are also frequently cited.
Why it matters
Common reference in pen test scopes and SAST rule sets. Useful as a baseline coverage check but never sufficient on its own for medical device security.
Related & references
Authoritative sources
Definition
Language- and platform-specific guidance (e.g., CERT C, MISRA) for writing software that resists common security defects.
Why it matters
Required evidence under IEC 81001-5-1. Reviewers want to see the standard, training records, and how violations are caught and remediated.
Related & references
Authoritative sources
Definition
A documented framework that shows security activities are integrated across the device lifecycle - not bolted on at the end. Includes secure requirements, threat modeling, secure coding, V&V, vulnerability management, and post-market response.
Why it matters
Reviewers want to see that security is a process, not a one-time test report. Without SPDF evidence, even a strong technical package can be flagged as immature.
Related & references
Authoritative sources
Definition
NIST SP 800-218 - set of practices for integrating security into the software development lifecycle. Maps cleanly to FDA SPDF expectations.
Why it matters
FDA's 2026 guidance and Executive Order 14028 both reference SSDF. Reviewers want to see secure development practices, not just secure outputs.
Related & references
Authoritative sources
Definition
A machine-readable inventory of every commercial, open-source, and off-the-shelf software component in the device. Must conform to NTIA Minimum Elements and include vulnerability status per component.
Why it matters
The SBOM is the foundation of postmarket vulnerability monitoring. A weak SBOM means a weak postmarket program - and weak postmarket programs are how Class I recalls happen.
Related & references
Authoritative sources
Definition
A structured analysis of how an attacker could compromise the device, organized by threat category (e.g. STRIDE - Spoofing, Tampering, Repudiation, Information disclosure, DoS, Elevation of privilege). Each threat is traced to a mitigation and to verification evidence.
Why it matters
Threat models are the most common source of FDA cybersecurity deficiencies. Reviewers want explicit threat-to-mitigation mapping, not a narrative.
Related & references
Authoritative sources
30-minute strategy session. No cost, no commitment - just answers from people who've shipped 250+ submissions.
