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.

Pick wrong and you eat a 60-day delay, or worse, an RTA after you have already filed.

Why this matters

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.

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 21 CFR 820.30.

When Cybersecurity Changes Fit the Special Pathway

These are the changes the FDA usually accepts as Special, assuming your design history file backs them up:

• 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 almost always force a Traditional submission, even if the code diff looks small:

• Enabling or disabling a wireless interface (BLE, Wi-Fi, NFC, cellular). Adding a radio expands attack surface; removing one changes 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.

If any of the above describe your change, do not file Special. You will get an RTA or a deficiency letter that costs more than the time you tried to save.

The Decision Tree

Is this a modification to YOUR OWN cleared device?
  No  --> Traditional (or new 510(k) entirely)
  Yes --> continue

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

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

The last step is not optional. Cybersecurity changes are exactly the category where reviewers' opinions vary, and a 15-page Pre-Sub is cheaper than a 60-day delay.

The Pre-Sub (Q-Sub) Move

A Pre-Submission 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]?"

Get a written answer before you build the submission.

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.
• 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. Full re-test is not required, but the scope rationale must be explicit.
• 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

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

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.

Any of these signal that the change is bigger than the submission admits, and the reviewer will ask for the Traditional package.

How This Aligns with the Feb 3, 2026 the FDA Guidance

The Feb 3, 2026 the FDA premarket cybersecurity guidance does not redefine 510(k) pathways - it defines the artifacts every premarket cybersecurity submission must contain. Special 510(k)s are not exempt. The guidance's expectation is that the depth of each artifact scales with the change, but the set of artifacts does not shrink.

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 cybersecurity deficiencies after our submission, we resolve them at no additional cost. Learn more about our specialized support at https://bluegoatcyber.com/services/fda-premarket-cybersecurity-services.

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

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)?

If it is the first time Secure Boot is enabled on the device, almost always yes. 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 days of acceptance, 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?