Special vs Traditional 510(k) for Cybersecurity Changes

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.

Key Takeaways

• Three 510(k) types: Traditional (90-day goal), Special (30-day goal), Abbreviated (90-day, leverages consensus standards).
• Special 510(k) is for your own cleared device, with well-established evaluation methods, and a summary-level review.
• Cybersecurity changes are a gray zone - the FDA looks at impact on the security risk profile and threat model, not just code diff size.
• Changes that expand attack surface, add wireless paths, or alter intended use almost always get bumped to Traditional.
• A Pre-Sub (Q-Sub) is the cheapest way to confirm the pathway before you build the submission package.
• Aligned with the Feb 3, 2026 the FDA premarket cybersecurity guidance and Section 524B(b) obligations.

The Three 510(k) Types in One Table

Type	Review Goal	When to Use	Cybersecurity Implication
Traditional	90 days	New device, new predicate, or substantive change to your own device	Full Section 524B(b) package: SBOM, threat model, SPDF evidence, pen test, architecture views
Special	30 days	Modification to your own cleared device, evaluable with well-established methods, summary-level review	Delta package: scoped threat model update, SBOM diff + VEX delta, regression test summary
Abbreviated	90 days	Submission leverages FDA-recognized consensus standards or special controls	Useful when relying on IEC 81001-5-1, AAMI SW96, or AAMI TIR57 declarations

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

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

FAQs

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