Special vs Traditional 510(k)

If you are modifying a cleared device for cybersecurity reasons - replacing an end-of-support library, hardening BLE, enabling Secure Boot, rotating a signing key infrastructure, or refreshing TLS - the first regulatory question is not what you are changing. It is which 510(k) type the change belongs in.

An unsuitable pathway can lead to conversion to Traditional and additional review; eSTAR uses technical screening, not the RTA checklist.

Why this matters

Changing a cleared or approved device? Start with the device changes decision guide, then see PMA supplement cybersecurity changes and Letter to file vs new 510(k).

Choosing the correct 510(k) pathway for cybersecurity changes impacts your time to market and regulatory burden. Missteps can lead to significant delays, including RTA (Refuse to Accept) decisions, costing manufacturers valuable resources and delaying patient access to improved medical devices. The FDA's February 3, 2026 final guidance, "Cybersecurity in Medical Devices," clarifies expectations, emphasizing the need for a thorough understanding of how cybersecurity modifications affect a device's safety and effectiveness. Working through the Special vs. Traditional 510(k) distinction, especially for changes involving software bill of materials (SBOM) updates, threat model revisions, or expanded attack surfaces, is critical. Adhering to standards like IEC 81001-5-1, AAMI SW96, and AAMI TIR57 can facilitate the Abbreviated pathway, but the material impact of a change often dictates a longer review. Early engagement with the FDA via a Pre-Submission is essential to confirm the appropriate regulatory path, preventing costly rework and accelerating clearance.

Official sources: FDA, Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions (February 2026); CISA Software Bill of Materials resources; FDA eSTAR Program; FDA Cybersecurity in Medical Devices FAQs (Section 524B).

The Three 510(k) Types in One Table

The Special pathway exists because the FDA does not want to re-review the entire device every time you swap a connector or refresh a component. It leans on your design controls and change-management records under the QMSR and ISO 13485:2016 clause 7.3.

When Cybersecurity Changes Fit the Special Pathway

These changes may be Special candidates if a new 510(k) is necessary and the evaluation and summary-review criteria are met:

• Cryptographic library version bumps with no algorithm change (e.g., OpenSSL 3.0.x to 3.0.y) where the API contract and threat model are unchanged.
• SBOM component refresh driven by end-of-support, where the replacement is a drop-in with equivalent or stronger security posture and no new network behavior.
• TLS minimum version raise (e.g., disabling TLS 1.1) that reduces attack surface without introducing new protocols.
• Signing key infrastructure rotation with no change to the signing algorithm, verification chain, or boot flow.
• Patch deployment for known vulnerabilities where the patch is vendor-supplied and the change is bounded.

The common thread: the change is defensive, bounded, and does not alter the device's security risk profile as documented in your threat model and security risk assessment.

When the FDA Will Push You to Traditional

These changes warrant careful evaluation, but do not automatically require a Traditional submission:

• Enabling or disabling a wireless interface (BLE, Wi-Fi, NFC, cellular). Adding a radio expands attack surface; removing one can affect functionality, but does not inherently change intended use.
• Adding a remote-access path - cloud telemetry, remote service portal, OTA update channel where none existed.
• First-time Secure Boot enablement on a device that previously had none. This changes the trust boundary and the recovery model.
• Firmware signing algorithm change (e.g., RSA-2048 to ECDSA-P256, or SHA-1 to SHA-256 in the verification chain). Different cryptographic primitives mean a different threat model.
• New third-party SBOM components with material function (not a drop-in replacement) - especially open-source components with unknown provenance or weak maintainer signals.
• Intended-use changes that bring the device into a new clinical context, new patient population, or new network environment.
• Architecture changes that affect any of the four architecture views the FDA expects: Global System, Multi-Patient Harm, Updateability/Patchability, or Security Use Case.

For each change, evaluate whether methods are well-established and results can be sufficiently reviewed in summary or risk-analysis form. Use Traditional when Special criteria are not met.

The Decision Tree

Does the modification require a new 510(k)?
  No --> Document the rationale and supporting evidence in the QMS.
  Yes --> Is it a modification to your own legally marketed device?
    No --> Traditional or another applicable pathway.
    Yes --> Are evaluation methods well-established and results
            reviewable in summary or risk-analysis form?
      Yes --> Special 510(k) candidate.
      No --> Traditional 510(k).

Does the change alter the device's security risk profile, threat model, attack surface, or intended use? Yes --> Traditional No --> continue

Can the change be evaluated using well-established methods (known test protocols, recognized standards, summary analysis)? No --> Traditional Yes --> continue

See also: Letter to File vs New 510(k), FDA 510(k) & PMA Cybersecurity Guide, and Indications for Use, Predicates, and Cybersecurity Scope.

Does the change introduce a new wireless path, remote-access channel, or third-party component with material function? Yes --> Traditional No --> Special 510(k) candidate - confirm via Pre-Sub

A Pre-Submission is optional. Feedback is nonbinding and does not guarantee acceptance of the selected pathway.

## The Pre-Sub (Q-Sub) Move

A [Pre-Submission](/services/fda-premarket-cybersecurity-services) for a Special vs Traditional pathway question should include:

1. **Change description** - what is being modified, scoped tightly. One paragraph.
2. **Threat model delta** - the specific STRIDE entries, attack trees, or asset/threat pairs that change. If none change, say so explicitly and show the diff.
3. **Security risk assessment delta** - updated rows in your ISO 14971 / AAMI TIR57 / ANSI/AAMI SW96:2023 risk table. Include residual risk before and after.
4. **SBOM diff** - components added, removed, version-bumped. Reference your CycloneDX or SPDX baseline.
5. **VEX delta** - any new affected/not_affected/fixed/under_investigation statuses driven by the change.
6. **Proposed verification** - what regression testing, pen test scoping, and labeling updates you intend.
7. **Specific question to the FDA** - "Does the FDA agree that the proposed change qualifies for the Special 510(k) pathway under [criteria]?"

Consider seeking written feedback if the pathway remains uncertain.

What a Special 510(k) Cybersecurity Package Actually Contains

When the Special pathway is accepted, the FDA still expects Section 524B(b) artifacts - just scoped to the change:

• Threat model update - delta only, with traceability to the baseline model on file.
• SBOM - full current SBOM, plus a diff document highlighting changes since the cleared baseline. CycloneDX 1.5+ or SPDX 2.3 with lifecycle fields.
• Optional VEX - updated VEX document covering any vulnerabilities introduced or resolved by the change.
• Security risk assessment update - updated rows, not a full rewrite.
• Regression pen test summary - scoped to the changed interfaces and components. The need for broader retesting depends on the impact analysis; document the scope rationale.
• Updated labeling - if the change affects user-facing security behavior (e.g., new pairing flow, changed update mechanism).
• Updated SPDF evidence - which Secure Product Development Framework controls were exercised for the change.

The package is smaller than a Traditional, but every artifact still needs to defend itself in isolation.

Reviewer Red Flags

If a reviewer sees any of these in a Special 510(k) cybersecurity package, expect a deficiency letter or a pathway bump:

• Threat model update with no traceability to the on-file baseline.
• SBOM with no diff document - reviewer has to compute it themselves.
• VEX with new vulnerabilities marked under_investigation and no remediation timeline.
• Regression pen test scope that excludes the changed interface ("we tested everything except the thing that changed").
• Labeling unchanged when user-facing security behavior changed.
• Security risk assessment with residual risk increased but no benefit-risk justification.

These gaps may prompt questions, but do not automatically require conversion to Traditional. Pathway eligibility depends on the Special 510(k) criteria.

How This Aligns with the Feb 3, 2026 FDA Guidance

The Feb 3, 2026 FDA premarket cybersecurity guidance does not redefine 510(k) pathways - it recommends cybersecurity evidence for applicable submissions. Special 510(k)s are not exempt. The guidance's expectation is that the depth of each artifact scales with the change, with the content and scope justified for the device and change; VEX is optional.

Section 524B(b)(1)-(3) obligations - plan to monitor/identify/address vulnerabilities, processes to provide reasonable assurance the device and related systems are cybersecure, and the SBOM - apply to every cyber device submission regardless of 510(k) type.

Related Reading

• Preparing Your eSTAR 510(k) Cybersecurity Documentation
• SBOM End-of-Support, EOL, and Level of Support: What the FDA Expects
• How Long Does FDA Cybersecurity Review Take?
• Medical Device Cybersecurity Risk Analysis: The FDA Playbook

Where the Abbreviated 510(k) fits

When Is an Abbreviated 510(k) the Right Move?

An Abbreviated 510(k) is the right move when performance can be demonstrated through conformity to one or more FDA-recognized consensus standards, an FDA-issued guidance document, or a special control. You submit summary reports and declarations of conformity instead of full test reports.

For a connected medical device, the standards that most often carry the Abbreviated pathway are IEC 62304 for software lifecycle, IEC 81001-5-1 for health-software security, and ANSI/AAMI SW96:2023 for security risk management. Verify the exact recognition number and version on the FDA's Recognized Consensus Standards database before filing - a declaration to an outdated edition is a common RTA trigger.

How Cybersecurity Requirements Differ by 510(k) Type

They do not differ in scope - Section 524B is pathway-agnostic. They differ in format and framing.

Traditional: Full narrative for every artifact. Threat model, SBOM with VEX, security architecture views (global, multi-patient harm, updateability, security use case), security risk assessment, pen test report, and postmarket plan - each with its own detailed evidence.

Special: Same seven artifacts, but scoped to the delta. The threat model updates the sections touched by the change. The SBOM shows before/after. The pen test focuses on the changed surface. Reviewers still expect a complete, standalone cybersecurity section in eSTAR.

Abbreviated: Same seven artifacts, but performance claims can reference a declaration of conformity. The SBOM and pen test still need to be filed as evidence - the standard does not replace them, it just lets you point to it for methodology.

If you are not sure a new 510(k) is needed at all, start with Letter to File vs New 510(k).

How Blue Goat approaches this

Blue Goat Cyber assists medical device manufacturers in strategically working through the FDA's 510(k) pathways for cybersecurity-driven changes. Our methodology focuses on a careful analysis of the proposed device modifications and their potential impact on security risk. We prepare Pre-Submission (Q-Sub) packages, framing your cybersecurity changes effectively to secure FDA agreement on the appropriate pathway and prevent costly rejections. Our team, composed of OSCP-certified penetration testers, CISSP-credentialed security architects, and former military red team members, understands the nuances of the FDA's expectations. We produce detailed documentation, including updated threat models, SBOM deltas, and verification test results, tailored for the chosen pathway. We are experienced in Section 524B(b) obligations. If the FDA raises a cybersecurity question, we answer it at no extra cost until the cybersecurity portion is closed. Learn more about our specialized support at FDA premarket cybersecurity services.

If you want one team to own the whole cybersecurity package, see our full-service FDA premarket cybersecurity submission support.

Need ongoing help reviewing software changes for their submission impact? See our medical device security advisory.

Related reading: SBOM for Third-Party Chip Firmware in Medical Devices.

FAQ

Can I use a Special 510(k) for a cybersecurity patch?

Sometimes. If the patch is vendor-supplied, bounded, does not alter the threat model, and can be evaluated with well-established methods, the Special pathway is a candidate. Confirm with a Pre-Sub before filing.

Does enabling Secure Boot require a Traditional 510(k)?

No automatic pathway rule applies. First determine whether a new 510(k) is needed, then assess Special eligibility using well-established methods and summary-review criteria. It changes the trust boundary, the recovery model, and the update flow - all of which materially shift the security risk profile.

What if I am swapping an end-of-support SBOM component?

If the replacement is a functional drop-in with equivalent or stronger security posture and no new network behavior, the Special pathway is plausible. If the replacement adds new dependencies, changes the API contract, or has different cryptographic behavior, expect to file Traditional.

Do I still need an SBOM for a Special 510(k)?

Yes. Section 524B(b)(3) requires an SBOM for every cyber device regardless of 510(k) type. For a Special, submit the full current SBOM plus a diff document against the cleared baseline.

How long does a Pre-Sub take?

The FDA's goal is a written response within 70 calendar days of receipt, with a meeting if requested. For a pathway-selection question, 70 days is faster than discovering mid-review that you filed wrong.

Related: Medical Device Cybersecurity: A Complete Lifecycle Guide

More on this topic

• Infusion Pump Cybersecurity: FDA
• HHS 405(d) HICP Practice #9 for 524B
• AAMI SW96 vs TIR57: Did SW96 Replace It?