The MedTech Cybersecurity Standards Decoder

Section 524B of the FD&C Act, IEC 81001-5-1, AAMI TIR57, ANSI/AAMI SW96, ISO 14971, and more. What they require, how they connect, and what the FDA expects to see. A plain-English field guide for Regulatory, Quality, Engineering, and Executive leaders shipping connected medical devices in 2026.

What's inside

Three jobs. Skim the executive brief for the board view. Use the standards decoder as your reference. Pin the connection map to your wall.

• The Executive Brief. Section 524B, board risk, premarket math.
• The Standards Decoder. 12 standards, one page each, same template.
• The Connection Map. How artifacts fan out across your eSTAR.
• How Blue Goat Cyber Fits. Three-step plan, credentials, track record.

Share this graphic: view the full infographic and text version.

The Executive Brief

Cybersecurity is now a clearance requirement. Not a best practice. Not a nice-to-have. A federal statute.

The one-paragraph version

Section 524B applies to cyber devices submitted through 510(k), PMA, PDP, De Novo, and HDE pathways. A cyber device includes sponsor-authorized software, can connect to the internet, and contains technological characteristics that could be vulnerable to cybersecurity threats. The February 3, 2026 final guidance recommends supporting documentation; guidance recommendations are not themselves binding requirements. eSTAR submissions undergo technical screening rather than the legacy RTA checklist.

The business risk in four numbers

• Submission delays can affect launch revenue; the impact depends on the product and review pathway.
• 510(k) additional-information responses are due within 180 calendar days.
• Launch costs should be modeled using product-specific assumptions, not a universal dollar estimate.
• Vulnerabilities require risk assessment; a CVE alone does not determine recall classification.

What the FDA can do under Section 524B

• Assess whether applicable cybersecurity submission obligations are met.
• Request additional information during substantive review.
• Evaluate postmarket vulnerability-management processes and plans.
• Coordinate on cybersecurity risks with other agencies as appropriate.
• Apply reporting requirements under 21 CFR Parts 803 and 806 when their criteria are met; not every cyber event is reportable.

Why MedTech cybersecurity is uniquely hard

Enterprise IT can patch on Tuesday. A connected infusion pump cannot. A pacemaker definitely cannot.

• Patient safety first. A blocked port that disrupts therapy can create a safety risk. ISO 14971 governs every cybersecurity control decision.
• 10 to 20 year device lifetime. The OS you ship in 2026 has to be defensible in 2040. SBOM and EOL planning are non-negotiable.
• You can't patch the field on demand. Updates need risk-based change control, deployment coordination, and assessment of whether a new submission is needed.

What "good" looks like to the FDA in 2026

The following eight evidence groupings are an editorial checklist, not a mandated review order:

1. Secure Product Development Framework (SPDF) - process-level evidence.
2. Cybersecurity Risk Assessment (per AAMI TIR57 or ANSI/AAMI SW96).
3. Threat Model (STRIDE or equivalent, with mitigations traced to requirements).
4. Software Bill of Materials (SBOM) in an industry-accepted, machine-readable format, such as SPDX or CycloneDX.
5. Security Architecture Views (Global System, Multi-Patient Harm, Updateability/Patchability, and Security Use Case).
6. Security Risk Management Plan and Report (linked to the ISO 14971 file).
7. Cybersecurity Test Reports (pen test, fuzz, vulnerability scan, malformed input).
8. Cybersecurity Management Plan (postmarket monitoring and coordinated disclosure).

The executive summary

• Risk. Incomplete evidence can delay review; quantify the business impact using your launch plan.
• Liability. The submitter is responsible for Section 524B compliance; the statute does not create a distinct executive cybersecurity attestation requirement.
• Mitigation. Three actions, in order: (1) gap-assess against the 8 artifacts above, (2) fix what's missing, (3) engage a specialist before, not after, the pre-sub meeting.
• Owner. The CISO or VP of Quality should report cybersecurity submission readiness to the board quarterly, alongside clinical and manufacturing risk.

The Standards Decoder

Twelve standards. One section each. Same template every time: What it is · What it requires · What the FDA expects to see · How it connects.

How to read this section. If a standard is in your scope, the "What the FDA expects to see" line describes potentially relevant supporting evidence. The "How it connects" line tells you which other standards feed into or out of it. Use the connection map below to see the whole web at once.

1. FDA Premarket Cybersecurity Requirements (21 USC §360n-2 (FD&C Act §524B) + Feb 3, 2026 Premarket Guidance)

Applies to: Cyber device marketing submissions (510(k), De Novo, PMA, PDP, and HDE), not IDEs.

What it is. Section 524B establishes binding obligations for covered cyber device marketing submissions. The February 3, 2026 final guidance superseded the June 27, 2025 final, primarily to align with the QMSR. It recommends documentation rather than mandating a fixed seven-section format.

What it requires.

• Processes and procedures providing reasonable assurance of cybersecurity across the lifecycle; the guidance recommends an SPDF.
• A plan to monitor, identify, and address postmarket vulnerabilities, including coordinated vulnerability disclosure.
• Processes for regular-cycle updates and patches and out-of-cycle patches as soon as possible for critical vulnerabilities presenting uncontrolled risk.
• A Software Bill of Materials (SBOM) including all commercial, open-source, and off-the-shelf components.

What the FDA expects to see. Evidence addressing applicable Section 524B obligations and the guidance recommendations. eSTAR technical screening precedes substantive review. The 180-calendar-day period is the 510(k) additional-information response deadline, not a universal review clock.

How it connects. Section 524B is the umbrella. Every other standard in this guide is one of the bricks. AAMI TIR57 and SW96 handle risk. IEC 81001-5-1 handles the SPDF. IEC 62304 handles the software lifecycle. They all land in one eSTAR cybersecurity section.

2. eSTAR Cybersecurity Submission (FDA eSTAR v7.1)

Applies to: 510(k), De Novo, and PMA submissions filed via eSTAR (mandatory for 510(k) and De Novo).

What it is. eSTAR is the FDA's electronic submission template, mandatory for most 510(k) submissions since October 2023 and De Novo submissions since October 1, 2025, subject to applicable exemptions. Version 7.1 is current. PMA eSTAR use is voluntary. Our eight evidence groupings are editorial rather than template-mandated. See our eSTAR comparison.

What it requires.

• Security architecture description with labeled network interfaces, data flows, and trust boundaries.
• Threat model using a structured framework (STRIDE or equivalent) with explicit threat-to-mitigation mapping.
• Machine-readable SBOM in an industry-accepted format, with supporting vulnerability assessment. The FDA does not prescribe a format or version; CISA published updated SBOM minimum elements on July 29, 2026.
• Cybersecurity risk assessment and SPDF documentation.
• Full-scope penetration test report with remediation disposition for every finding at every severity level.
• Vulnerability management plan with formal CVD policy and a documented secure update mechanism.
• Postmarket monitoring and patching plan, plus cybersecurity labeling for the user.

What the FDA expects to see. Complete applicable cybersecurity fields consistently with supporting attachments and follow current eSTAR attachment instructions. Technical screening and substantive review are distinct; the 180-calendar-day additional-information response deadline is not a universal screening duration.

How it connects. eSTAR is the delivery mechanism for everything else in this guide. Each upload slot is fed by one or more underlying standards. Note: section letters have shifted between eSTAR major versions, so always verify against the version you've downloaded from the FDA.

3. AAMI TIR57:2016 (R2023) - Principles for Medical Device Security: Risk Management

Applies to: Cybersecurity risk management for any medical device.

What it is. The MedTech-specific extension of ISO 14971 for cybersecurity. TIR57 is how you do security risk management (asset identification, threat analysis, vulnerability assessment, risk evaluation, and risk control) in a way the FDA recognizes and expects.

What it requires.

• Identification of cybersecurity assets, threats, and vulnerabilities.
• Estimation of likelihood and severity using a security-aware scheme.
• Risk evaluation and decisions on acceptability.
• Risk control measures with verification.
• A documented, traceable risk file separate from but linked to the ISO 14971 safety file.

What the FDA expects to see. A Cybersecurity Risk Assessment that follows TIR57 (or ANSI/AAMI SW96) structure. The assessment must cover every interface and every component in the SBOM. It must trace threats to mitigations and include a residual risk acceptability statement.

How it connects. TIR57 is the operational manual for the security side of risk management. It feeds the threat model, the risk assessment, and the security architecture, all required eSTAR uploads. ANSI/AAMI SW96 (Standard 5) works with TIR57 and TIR97.

4. AAMI TIR97:2019/(R)2023 - Principles for Medical Device Security: Postmarket Risk Management

Applies to: Any cleared or approved device with a cybersecurity profile.

What it is. The postmarket companion to TIR57. Tells you how to keep doing security risk management after the device ships: CVE monitoring, vulnerability triage, patch management, coordinated disclosure, and MDR/MedWatch integration.

What it requires.

• A postmarket cybersecurity surveillance program (CVE monitoring, threat intel, customer reports).
• A vulnerability triage process tied to your TIR57 / SW96 risk file.
• Coordinated vulnerability disclosure (CVD) consistent with ISO/IEC 30111 and 29147.
• Defined criteria for when a vulnerability requires patching, mitigation, or recall.
• Reporting assessment under 21 CFR Parts 803 and 806 when applicable.

What the FDA expects to see. A Cybersecurity Management Plan that operationalizes TIR97. It must show who monitors what, on what cadence, and how new vulnerabilities are triaged, patched, and disclosed. Section 524B requires regular-cycle patches and out-of-cycle patches as soon as possible for critical vulnerabilities presenting uncontrolled risk; it sets no numeric severity-based deadlines.

How it connects. TIR97 closes the loop on TIR57. It feeds the vulnerability management plan in the eSTAR cybersecurity section and is the backbone of any postmarket surveillance argument to the FDA.

5. ANSI/AAMI SW96:2023 - Standard for Medical Device Security: Security Risk Management

Applies to: Full lifecycle security risk management for medical devices.

What it is. The newer (2023) consensus standard that works with TIR57 and TIR97 to support a lifecycle security risk management framework. The FDA's February 3, 2026 guidance explicitly references SW96 alongside TIR57 as acceptable frameworks.

What it requires.

• A documented security risk management process spanning premarket and postmarket.
• Asset, threat, vulnerability, and risk identification methodology.
• Risk acceptance criteria reviewed by management.
• Verification that risk controls work as intended.
• Traceability between security risks and safety risks (ISO 14971 alignment).

What the FDA expects to see. A documented security risk management program with applicable standards and methods identified. SW96 works with, rather than replaces, TIR57 and TIR97.

How it connects. SW96 is the convergence standard. It does not replace TIR57 or TIR97. Still requires ISO 14971 alignment for the safety-security interface and feeds the same eSTAR uploads as TIR57+TIR97. For a side-by-side breakdown, see AAMI TIR57 vs TIR97 vs SW96.

6. ISO 14971:2019 + ISO/TR 24971 - Risk Management for Medical Devices

Applies to: Every medical device. The bridge between safety and security.

What it is. The foundational risk management standard for medical devices, the one your QMS already lives in. Cybersecurity harms (data breach, device malfunction via cyber attack, patient injury from compromised therapy) are hazardous situations under ISO 14971. Cybersecurity controls that could create new safety hazards must also be evaluated here.

What it requires.

• Risk management process integrated into the device lifecycle.
• Hazard identification, risk estimation, and risk evaluation.
• Risk control measures verified for effectiveness.
• Overall residual risk acceptability decision.
• Risk management report signed by management.

What the FDA expects to see. An ISO 14971 risk file that explicitly includes hazardous situations originating from cybersecurity vulnerabilities. The file must be cross-referenced to the TIR57/SW96 security risk file. Reviewers will look for the connection. Document this connection to support review.

How it connects. ISO 14971 is the spine. TIR57/SW96 produces the security side of the inputs. IEC 62304 produces the software anomaly side. All three feed a single unified risk file that covers both safety and security in the eSTAR submission.

7. IEC 62304:2006/AMD1:2015 - Medical Device Software Lifecycle Processes

Applies to: Any device containing software (Class A, B, or C).

What it is. The software lifecycle standard for medical devices. Defines what "controlled software development" means: planning, requirements, architecture, detailed design, implementation, integration, system testing, maintenance, and problem resolution. IEC 62304 is a voluntary consensus standard for device software lifecycle processes, and its SOUP (Software of Unknown Provenance) list is the direct input to the SBOM.

What it requires.

• Software development planning with safety classification (A/B/C).
• Requirements management and software architecture documentation.
• Coding, integration, and system-level testing per the safety class.
• SOUP (Software Of Unknown Provenance) identification and risk control.
• Problem resolution, change control, and configuration management records.

What the FDA expects to see. A complete IEC 62304 software lifecycle file, including SOUP list, anomaly reports, and configuration management records. The SOUP list must be reconciled against the SBOM. Mismatches between the SOUP list and SBOM can indicate inconsistent documentation.

How it connects. IEC 62304 governs how software is built. IEC 81001-5-1 (Standard 8) overlays security activities on top of the IEC 62304 lifecycle. The SOUP list feeds the SBOM. Anomaly reports feed the risk file. Everything lands in the eSTAR software documentation and cybersecurity sections.

8. IEC 81001-5-1:2021 - Health Software Security

Applies to: Any health software, including medical device software.

What it is. The Secure Product Development Framework (SPDF) standard. The FDA's February 3, 2026 guidance explicitly references IEC 81001-5-1 as the SPDF framework. It maps security activities (threat modeling, security requirements, secure design, security verification, vulnerability management) to each phase of the IEC 62304 lifecycle.

What it requires.

• Security activities mapped to each phase of the IEC 62304 lifecycle.
• Threat modeling and security risk management throughout development.
• Secure design, secure coding practices, and security verification.
• Software composition analysis (feeds SBOM).
• Security update and patch management process.
• Decommissioning and end-of-life security activities.

What the FDA expects to see. An SPDF document that maps every IEC 81001-5-1 activity to where in your QMS it lives. Reviewers will check that the SPDF is not a template. It must be device-specific and trace to your actual procedures and records.

How it connects. IEC 81001-5-1 is the SPDF answer for the FDA. It overlays IEC 62304 (Standard 7) with security. It produces inputs for the threat model, the SBOM, and the vulnerability management plan. IEC 62443-4-1 (Standard 9) is the industrial-controls alternative.

9. IEC 62443-4-1:2018 - Security for Industrial Automation and Control Systems

Applies to: Secure development lifecycle for connected products (often cited alongside 81001-5-1).

What it is. The industrial-controls cousin of IEC 81001-5-1. Many MedTech companies, especially those with IoT or OT components, use IEC 62443-4-1 as their SPDF framework. The FDA accepts it as SPDF evidence when the mapping to medical device cybersecurity requirements is explicit.

What it requires.

• A documented Secure Development Lifecycle (SDL) with eight practices.
• Threat modeling and security requirements management.
• Secure-by-design architecture and secure coding standards.
• Security verification and validation testing.
• Defect management and security update management.
• Process verification: independent assessment that the SDL is followed.

What the FDA expects to see. The FDA accepts IEC 62443-4-1 conformance as evidence of an SPDF, particularly when paired with an explicit mapping to the February 3, 2026 guidance sections. Third-party SDL assessments (not full certification) are acceptable and add credibility.

How it connects. IEC 62443-4-1 is an alternative or complement to IEC 81001-5-1. Pick one as your SPDF answer. Some companies use 62443-4-1 for OT/IoT components and 81001-5-1 for the software layers. Both feed the same eSTAR SPDF upload slot.

10. UL 2900-1 / UL 2900-2-1 - Software Cybersecurity for Network-Connectable Products

Applies to: Network-connectable medical devices (UL 2900-2-1 is the MedTech profile).

What it is. A testable cybersecurity standard with a defined laboratory evaluation methodology. UL 2900-2-1 is the medical device profile. A UL 2900-2-1 evaluation produces a test report that can serve as the cybersecurity testing artifact in the eSTAR submission.

What it requires.

• Software weakness analysis (CWE-based static and dynamic testing).
• Vulnerability analysis (CVE matching against the SBOM).
• Penetration testing against the device's exposed interfaces.
• Risk control assessment and security risk management evidence.
• Documented security capabilities (auth, crypto, audit, etc.).

What the FDA expects to see. A UL 2900-2-1 evaluation report can serve as the cybersecurity testing artifact in the eSTAR cybersecurity section. The FDA has recognized UL 2900-2-1 in multiple guidance documents. The report must be current and cover the as-submitted device configuration.

How it connects. UL 2900 is a testing and evidence standard, not a process standard. It validates what your SPDF (IEC 81001-5-1 or 62443-4-1) produced. It consumes the SBOM and the threat model as inputs and produces the pen test report as output.

11. NIST SP 800-115 + 800-30 + CVSS v3.1/v4.0 - Security Testing & Vulnerability Scoring

Applies to: How penetration testing and vulnerability scoring should be performed.

What it is. Useful references for security testing (800-115) and vulnerability scoring (CVSS); neither is a universally mandated methodology. NIST 800-30 provides the risk assessment methodology referenced in the February 3, 2026 guidance.

What it requires.

• Pen test reports that follow NIST 800-115 phases (planning, discovery, attack, reporting).
• Threat-informed test scope tied to your threat model (TIR57/SW96 outputs).
• Vulnerabilities scored with CVSS and contextualized for MedTech (medical impact, not just IT impact).
• Risk assessment rationale per NIST 800-30 where applicable.
• Independent tester credentials documented in the report.

What the FDA expects to see. A pen test report that names the methodology, lists the test scope, ties findings to threat model entries, explains finding severity and clinical context, and documents the remediation disposition (fixed, mitigated, or accepted with rationale) for every finding at every severity level.

How it connects. NIST 800-115 and CVSS feed the testing portion of the eSTAR cybersecurity section. They consume outputs from the threat model (TIR57/SW96) and SBOM (CVE matching) and produce the pen test report that goes into the eSTAR testing upload slot.

12. EU MDR 2017/745 + IVDR 2017/746 + MDCG 2019-16 - EU Cybersecurity Expectations

Applies to: Devices placed on the EU market under MDR or IVDR; UK requirements require a separate assessment.

What it is. The EU's regulatory framework for medical devices, with cybersecurity expectations laid out primarily in MDR Annex I (General Safety and Performance Requirements, GSPR 17) and the MDCG 2019-16 guidance document.

What it requires.

• IT security in the design and manufacture of the device (MDR Annex I, GSPR 17.2).
• Minimum requirements for hardware, IT network characteristics, and IT security measures (GSPR 17.4).
• Documentation in the technical file demonstrating cybersecurity assessment.
• Postmarket surveillance integrating cybersecurity (PSUR / PMSR).
• Coordinated vulnerability disclosure expectations consistent with ENISA guidance.

What the FDA expects to see. EU conformity evidence does not replace FDA submission obligations. EU technical documentation should address the applicable MDR or IVDR requirements and relevant MDCG guidance.

How it connects. EU MDR/IVDR is a parallel regulatory regime. The good news: the underlying standards (ISO 14971, IEC 62304, IEC 81001-5-1) are shared. Evidence can be reused, but assess and document jurisdiction-specific gaps.

The Connection Map

Standards do not live in isolation. Each one produces an artifact, and each artifact ends up in a specific slot in the eSTAR cybersecurity section. This table shows the flow.

Read it as a flow

• Process standards (IEC 81001-5-1, IEC 62304, IEC 62443-4-1) define how you develop securely.
• Risk standards (AAMI TIR57/SW96 + ISO 14971) define what the threats and controls are, and reconcile them against patient safety.
• Testing standards (NIST 800-115, UL 2900-2-1, CVSS) provide evidence the controls work.
• Postmarket standards (AAMI TIR97/SW96, ISO/IEC 30111+29147) define how you keep the device secure for its full lifetime.
• All four streams converge into the eSTAR cybersecurity section as your submission package.

How Blue Goat Cyber Fits

You do not need another framework deck. You need an evidence package built to the FDA's February 3, 2026 final guidance.

The three-step plan

1. Discovery Session. 30-minute call. We map your device, your standards scope, and your submission timeline. You leave with a one-page gap assessment and a fixed-fee proposal.
2. Evidence Build. We produce or refine the eight artifacts the FDA expects: SPDF, threat model, risk assessment, SBOM, security architecture, pen test, vulnerability management plan, and labeling.
3. Submission & Defense. We write the cybersecurity sections of your eSTAR, support the pre-sub if you want one, and respond to any FDA deficiency letters on cybersecurity grounds, on our dime.

Why MedTech leaders choose us

• MedTech only. Every engagement is a medical device. We don't split focus with enterprise IT clients.
• Deficiency-response commitment. If the FDA raises a cybersecurity deficiency on a package we authored, we respond at no additional cost within the agreed scope; clearance is not guaranteed. Track record: 275+ FDA submissions supported, zero cybersecurity rejections.
• SDVOSB certified. Service-Disabled Veteran-Owned Small Business. Federal-grade discipline.
• Standards-fluent. We map every deliverable to the current AAMI, IEC, and ISO standards and the FDA guidance reviewers apply.

Frequently asked questions

Which cybersecurity standards does the FDA actually cite?

The February 3, 2026 final premarket cybersecurity guidance references AAMI TIR57 (security risk management), ANSI/AAMI SW96:2023 (security risk management for the device life cycle), IEC 81001-5-1 (health software security), ISO 14971 (risk management), and IEC 62304 (software lifecycle). Section 524B is the binding statute; the standards are the operational interpretation reviewers apply when they measure your submission.

Is IEC 81001-5-1 mandatory for FDA submissions?

IEC 81001-5-1 is voluntary. Mapping security lifecycle activities to it can organize evidence, but does not guarantee faster review or eliminate deficiencies.

How does ANSI/AAMI SW96 differ from AAMI TIR57?

TIR57:2016/(R)2023 provides premarket security risk management guidance, while TIR97:2019/(R)2023 addresses postmarket management. SW96:2023 sets lifecycle security risk management requirements and works with both reports; it does not supersede them.

Do we need to comply with IEC 62443 for medical devices?

IEC 62443 is not automatically mandatory because a device connects to an operational technology network. Assess applicable legal, contractual, and system requirements. IEC 62443-4-1 can complement a medical device secure development program where relevant.

What is the relationship between Section 524B and the standards?

Section 524B is binding law for covered cyber device submissions. It requires a postmarket monitoring and disclosure plan, cybersecurity processes including updates and patches, and an SBOM to the FDA. Recognized consensus standards are generally voluntary ways to organize supporting evidence, not substitutes for those obligations.

Which standards apply to AI/ML medical devices?

ISO/IEC 23894 and the NIST AI Risk Management Framework are complementary AI risk references. The FDA finalized its AI-enabled device software function PCCP guidance on December 4, 2024, and updated it in August 2025. A PCCP is optional and can support specified planned modifications when authorized; it is not mandatory for every AI-enabled device.

Book a 30-Minute Discovery Session

No prep required. Bring your device description and your target submission date. You leave with a one-page gap assessment, regardless of whether you engage us.

Book Your Discovery Session

Our promise. We respond within 24 hours with a quote. Tell us about your device, your timeline, and your submission type. No sales pressure, just a clear, honest assessment and a fixed-price quote.

This guide is provided free of charge by Blue Goat Cyber. It is informational and does not constitute legal or regulatory advice.

bluegoatcyber.com · (844) 939-4628

Where to go next

• AAMI CR515:2025 and ML device cybersecurity - the ML-specific consensus report for machine learning-enabled devices, and the CR515 crosswalk tool.
• HHS HPH CPGs for Medical Device Manufacturers - how the healthcare sector performance goals land on manufacturers.
• Legacy Medical Device Cybersecurity - which standards still apply to unsupported platforms.
• IEC 60601 and Cybersecurity - why the 60601 family sets no security requirements, and the one place it belongs in your security risk analysis.
• ISO/TR 80002-2 and Validating Cybersecurity Tools - the standard that covers your toolchain rather than your device, and why SBOM generators and scanners need validation evidence.
• Post-Quantum Cryptography for Medical Devices - the FIPS 203, 204, and 205 standards, the SP 800-208 signing options, and the migration deadlines set by device service life.
• Standards Mapper - pick your device type and use case to get the applicable chain and its deliverables.

References

Primary sources cited or relied on in this guide:

• ANSI/AAMI SW96:2023, Standard for Medical Device Security, AAMI/ANSI
• AAMI TIR57:2016/(R)2023, Principles for medical device security: risk management, AAMI
• AAMI TIR97:2019, Principles for medical device security: postmarket risk management, AAMI
• IEC 81001-5-1:2021, Health software and health IT systems safety, effectiveness, and security, IEC/ISO
• ISO 14971:2019, Application of risk management to medical devices, ISO
• Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions (Feb 2026 final), U.S. FDA
• IMDRF Principles and Practices for Medical Device Cybersecurity, IMDRF