The MedTech Cybersecurity Glossary.

Why it matters

If your device meets all three criteria, the full premarket cybersecurity package is mandatory.

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.

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.

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.

Why it matters

Cybersecurity is no longer a 'best practice' - it is a federal statutory requirement. 21 CFR 807.81 sets the 90-day 510(k) timing floor; Section 524B decides whether that 21 CFR 807.81 filing is even accepted. Reviewers cite Section 524B and 21 CFR 807.81 together on every cyber-device RTA. Executive teams are accountable for cybersecurity attestation under Section 524B and 21 CFR 807.81 in the same way they are for clinical and manufacturing risk.

Why it matters

Cybersecurity AI-letter responses are often the difference between clearance and a multi-month delay.

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.

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.

Why it matters

Defines the controlled-vs-uncontrolled risk framework that determines whether a vulnerability can be handled as a routine update or starts the 30-day customer communication and 60-day fix timelines. Misclassifying a vulnerability is one of the fastest ways to draw a Warning Letter.

Why it matters

Operationalizes Section 524B. Missing a required section can trigger an RTA before the 180-day clock starts.

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.

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.

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.

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.

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.

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.

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.

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.

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.

Why it matters

Hospital security teams will benchmark your device against NIST CSF during procurement. A clear mapping accelerates sales and shortens RFP cycles.

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.

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.

Why it matters

Reviewers expect a documented inventory of every entry point - physical ports, wireless, APIs, update channels, debug interfaces. Undocumented surfaces become deficiencies.

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.

Why it matters

Misclassifying residual risk is one of the fastest ways to draw a Warning Letter. An **uncontrolled** risk that requires action triggers customer notification, a postmarket cybersecurity correction, and reporting under 21 CFR 806 / 803 - often on accelerated timelines once a KEV-listed CVE is involved. A defensible "controlled" call requires written evidence of exploitability analysis, harm linkage, and compensating controls. **Worked example.** A CVSS 9.8 RCE in an unauthenticated TLS library inside an infusion pump that ships with no network exposure and signed-firmware secure boot may be **controlled** (no realistic exploit path to harm). The same library in a network-connected patient monitor with default credentials and KEV listing is **uncontrolled** until patched - notify, mitigate, and report. **Decision flow:** (1) Is the vulnerability reachable in the deployed configuration? (2) Does exploitation lead to a patient-safety hazard (ISO 14971 linkage)? (3) Are compensating controls + monitoring sufficient until a patch ships? Any "no" → uncontrolled. For the full premarket workflow tying this back into the ISO 14971 safety file and the AAMI TIR57 security file, see the hazard-analysis convergence guide.

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.

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.

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.

Why it matters

CAPEC patterns make abstract STRIDE threats concrete and testable. Helpful for traceability between threat → test case → mitigation.

Why it matters

CVE IDs are the lingua franca of SBOM monitoring, VEX statements, KEV listings, and FDA postmarket evidence. Every CVE affecting a component in your SBOM needs a documented triage decision - exploitable, not exploitable, fixed, or under investigation - tied back to the underlying CWE and a patient-harm assessment.

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. Pair with CVE: a CVE says "this product, this version, this bug"; the CWE says "this is the underlying weakness class."

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.

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.

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.

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.

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.

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.

Why it matters

Less common than purl/CPE in MedTech but useful for tracking installed software inventories on customer-side gateways and workstations.

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.

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.

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.

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.

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.

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.

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.'

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.

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.

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.

Why it matters

Necessary but not sufficient for FDA. A vuln assessment proves coverage; a penetration test proves exploitability. The submission needs both.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

Why it matters

Drift is a postmarket cybersecurity AND clinical performance issue. FDA expects monitoring with defined triggers for retraining or field action.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

Why it matters

Threat models are the most common source of FDA cybersecurity deficiencies. Reviewers want explicit threat-to-mitigation mapping, not a narrative.