Special 510(k) for Software and Cybersecurity Changes: Decision Tree and Evidence Package
Decision tree for when a software or cybersecurity update can use Special 510(k) vs Traditional 510(k) — risk analysis, V&V summary, FDA guidance, and evidence package requirements.
What This Article Covers
This article addresses a narrow but high-stakes question: when can a manufacturer use a Special 510(k) for a software or cybersecurity modification to an existing cleared device, and what does the evidence package look like?
It provides a decision tree for navigating the Special 510(k) vs. Traditional 510(k) choice, the specific evidence needed for software and cybersecurity changes, and practical guidance on the eSTAR submission format. It also covers how QMSR (effective February 2, 2026) changes the design control terminology and documentation expectations for these submissions.
What This Article Does NOT Cover
This is not a general introduction to the 510(k) process, change control procedures, or cybersecurity fundamentals. It does not cover Abbreviated 510(k) submissions, De Novo classification, or PMA supplements. For broader context on those topics, see the complete guide to FDA 510(k) submissions and the medical device change control guide.
Special 510(k) for Software Changes -- Background
The Special 510(k) Program was established in 1998 and significantly updated by the FDA's 2019 guidance, "The Special 510(k) Program." The core premise is straightforward: when a manufacturer modifies a device it already holds clearance for, and the modification can be adequately reviewed through the design control process outputs, the manufacturer can submit those process outputs as the basis for the substantial equivalence determination rather than full performance test data.
For software changes specifically, this means the manufacturer submits summary information from verification and validation (V&V) activities, updated risk analysis, and design control documentation. The FDA reviews whether the design control process was followed and whether the outputs support the conclusion that the modified device remains substantially equivalent to the previously cleared version.
Two FDA guidance documents form the regulatory foundation for software-change 510(k) decisions:
- "Deciding When to Submit a 510(k) for a Software Change to an Existing Device" (October 2017) -- provides flowcharts and risk-based criteria for determining whether a software change requires a new 510(k), and if so, which type.
- "The Special 510(k) Program" (September 2019) -- establishes the conditions under which a Special 510(k) is appropriate, including the requirement that the manufacturer's own previously cleared device serves as the predicate and that the change can be reviewed through design control process outputs.
Key parameters that distinguish the pathways:
| Parameter | Special 510(k) | Traditional 510(k) |
|---|---|---|
| FDA review goal | ~30 days (not guaranteed) | 90 days statutory goal; ~146 days average in 2025 |
| Predicate | Your own previously cleared device | Any legally marketed device |
| Evidence format | Design control process summaries | Full performance data |
| Intended use change | Not permitted | Permitted |
| Conversion | FDA may convert to Traditional if inappropriate | N/A |
If the FDA determines during review that a Special 510(k) is not appropriate for the submitted change, it converts the submission to a Traditional 510(k). The original receipt date is preserved, so the manufacturer does not lose its place in the queue. However, the manufacturer must then supplement the submission with the additional information required for a Traditional review, which may result in an Additional Information (AI) request and a significantly longer timeline.
The Decision Tree: Special 510(k) vs. Traditional 510(k) for Software/Cybersecurity Changes
The following decision tree provides a structured framework for determining the appropriate submission type. Work through the nodes sequentially. If you reach a "Traditional 510(k)" conclusion at any node, stop -- a Traditional submission is the appropriate pathway.
Node 1: Is the change solely to strengthen cybersecurity with no other impact on software or device functionality?
- YES -- No 510(k) is likely needed. Document this determination in a Letter to File within your quality system. The rationale should address why the change does not affect safety or effectiveness, citing the risk analysis. Maintain the supporting documentation in the Design History File (DHF) / Design and Development File under QMSR terminology.
- NO -- Proceed to Node 2.
Important: This applies only to changes that are purely cybersecurity hardening -- for example, patching a known vulnerability in a third-party library without modifying device functionality, updating encryption algorithms, or closing an unused network port. If the cybersecurity change also modifies device behavior, alters the user interface, or affects any clinical functionality, proceed to Node 2.
Node 2: Does the change affect the intended use or indications for use?
- YES -- Traditional 510(k) required. A Special 510(k) cannot be used when the intended use changes. This is a hard rule -- there are no exceptions.
- NO -- Proceed to Node 3.
Node 3: Does the change introduce new risks or significantly modify existing risks?
Apply the risk analysis methodology per ISO 14971 to the proposed change. Consider both clinical risks and cybersecurity risks.
- YES -- Proceed to Node 3a.
- NO -- Proceed to Node 4.
Node 3a: Can the new or modified risk controls be verified through well-established methods?
"Well-established" means the verification method is recognized in relevant standards (e.g., IEC 62304 software unit testing, integration testing) and has been used previously for similar changes on this device or device type.
- YES -- Special 510(k) may be appropriate. Proceed to Node 4 for additional checks.
- NO -- Traditional 510(k). If the risk controls require novel or complex verification methods, the FDA will need to review the full data.
Node 4: Does the change significantly affect clinical functionality or performance specifications?
- YES -- Traditional 510(k) is the safer choice. Significant changes to clinical functionality -- for example, modifying a diagnostic algorithm's sensitivity or specificity, changing alarm thresholds, or altering therapy delivery parameters -- generally warrant the fuller review of a Traditional submission.
- NO -- Proceed to Node 5.
Node 5: Does the change modify the software architecture or operating environment?
Architecture changes include modifications to the software's modular structure, inter-process communication, thread management, or memory allocation. Operating environment changes include migration to a new OS version, change of processor, or modification of the runtime environment.
- YES -- Proceed to Node 5a.
- NO -- Proceed to Node 6.
Node 5a: Can the architecture change be reviewed in summary format?
- YES -- Special 510(k) appropriate, provided all other nodes support it. Include a clear architecture change summary, the rationale, and evidence that regression testing confirms no adverse impact.
- NO -- Traditional 510(k). Major architectural restructuring typically requires the FDA to review detailed test data and traceability.
Node 6: Is the method to evaluate the change well-established, and can results be reviewed in summary or risk analysis format?
This is the final gate. The Special 510(k) depends on the FDA being able to assess substantial equivalence through process summaries rather than raw data.
- YES -- Special 510(k) is appropriate. Prepare the evidence package as described in the next section.
- NO -- Traditional 510(k).
Cybersecurity-Specific Supplementary Questions
Software changes that involve cybersecurity dimensions require additional assessment beyond the main decision tree:
Does the change add new connectivity? (USB, Bluetooth, NFC, Wi-Fi, cloud endpoints, or any new communication interface)
- YES -- Traditional 510(k) is likely required. New connectivity introduces new attack surfaces, modifies the threat model, and may create new risks that cannot be adequately summarized in a Special submission.
Does the change significantly modify the Software Bill of Materials (SBOM)? (new SOUP [Software of Unknown Provenance] with higher risk profile, new third-party libraries, or major version upgrades of existing components)
- Assess risk impact. If the SBOM change is limited to minor version patches with equivalent functionality, a Special 510(k) may work. If the change introduces new SOUP with different risk characteristics, consider Traditional.
Does the change affect the threat model? (modifies the attack surface, introduces new trust boundaries, changes authentication or authorization mechanisms)
- YES -- Traditional 510(k) is safer. Threat model modifications indicate that the cybersecurity risk profile has materially changed, and the FDA will want to review the updated threat model and associated controls in full.
Evidence Package for Special 510(k) -- Software/Cybersecurity
A Special 510(k) for a software or cybersecurity change must contain enough information for the FDA to determine substantial equivalence through the design control process outputs. The following table maps each evidence component to its source documentation and the relevant DHF/DDF section.
| Component | Content | Source Document | DHF/DDF Section |
|---|---|---|---|
| Risk analysis summary | Updated ISO 14971 risk analysis applied to the software change; hazard identification, risk estimation, risk control measures, residual risk evaluation | Risk Management File | Risk Analysis Report, Risk Control Measures |
| Software V&V summary | Summary of verification and validation activities per IEC 62304; unit testing, integration testing, system testing results in summary form | Software V&V Report | Design Verification / Design Validation |
| Cybersecurity risk assessment update | Updated cybersecurity risk assessment documenting new vulnerabilities, changed threat landscape, and adequacy of security controls | Cybersecurity Risk Assessment | Security Risk Management File |
| Threat model update | STRIDE or similar threat model reflecting the modified software architecture or operating environment; updated attack trees if applicable | Threat Model Document | Security Architecture |
| SBOM update | Updated Software Bill of Materials reflecting all software component changes, including version updates, additions, and removals | SBOM (machine-readable + human-readable) | Design Transfer / Configuration Management |
| Traceability matrix | Requirements to risks to tests to results; demonstrates complete coverage of the change | Requirements Traceability Matrix | Design Inputs / Design Outputs |
| Design control process documentation | Evidence that the change was processed through the full design control procedure: design input review, design output review, design review, verification, validation, design transfer, design change | Design Control Records | Design and Development Planning / Design Review |
| Labeling changes | Updated Instructions for Use (IFU) reflecting any cybersecurity features, warnings, or modified user instructions | Labeling / IFU | Design Outputs -- Labeling |
| Section 524B cybersecurity documentation | For cyber devices: cybersecurity plan, SBOM, process for coordinated vulnerability disclosure, post-market update and patch management plan | Cybersecurity Plan | Design Outputs / Post-Market Plan |
Each component should be submitted as a summary, not as the full underlying data. The FDA's expectation is that the design control process was followed rigorously and that the summary accurately reflects the process outputs. If the FDA needs to see underlying data, it will issue an AI request -- and at that point, the submission may be converted to a Traditional 510(k).
When Traditional 510(k) Is Safer Even If Special Might Qualify
The decision tree above identifies situations where a Special 510(k) is technically possible. However, there are scenarios where choosing a Traditional 510(k) is the more prudent regulatory strategy, even when a Special could qualify:
Significant cybersecurity architecture changes. If the change restructures the security architecture -- for example, moving from a flat network model to a segmented architecture, implementing a new authentication framework, or changing the encryption scheme -- the FDA will want to review the full security architecture documentation, not a summary.
New connectivity features. Adding any new communication interface (Bluetooth, Wi-Fi, NFC, USB, cloud API) introduces a new attack surface. Even if the design control process is straightforward, the FDA has historically scrutinized new connectivity features closely, particularly in the post-Section 524B era.
Changes that substantially modify the threat model. If the threat model changes in material ways -- new threat actors, new attack vectors, changed trust boundaries -- the FDA needs to evaluate the full updated threat model and the associated security controls. A summary is unlikely to satisfy the reviewer.
FDA's February 2026 cybersecurity guidance alignment with QMSR. The FDA's Level 2 revised cybersecurity guidance (February 3, 2026) introduced updated expectations aligned with QMSR and ISO 13485. If your device is a cyber device subject to Section 524B, the FDA has heightened expectations for cybersecurity documentation. A Traditional 510(k) gives you more room to provide the full cybersecurity evidence package.
Devices with existing FDA cybersecurity concerns or prior AI requests. If your device has a history of cybersecurity-related AI requests, the FDA is more likely to scrutinize a Special submission closely and potentially convert it. A Traditional submission signals transparency and may result in a smoother review.
When you need a new predicate comparison. If the cumulative effect of multiple incremental changes makes it difficult to clearly compare the modified device to your original clearance, a Traditional 510(k) allows you to reset the comparison and establish a clean substantial equivalence argument.
The risk of choosing Special when Traditional is safer is not hypothetical. When the FDA converts a Special 510(k) to Traditional during review, you must supplement the submission with full data, which triggers an AI request and extends the timeline from the hoped-for 30 days to the full Traditional review cycle. The original receipt date is preserved, but the clock restarts on the substantive review.
QMSR Impact on Software Change 510(k) Submissions
The Quality Management System Regulation (QMSR), effective February 2, 2026, incorporates ISO 13485:2016 by reference and replaces much of the former Quality System Regulation (QSR). For manufacturers submitting Special 510(k) notifications for software changes, the terminology and structural changes in QMSR affect how design control documentation is referenced and organized.
Terminology Changes
| Legacy QSR Term | QMSR / ISO 13485 Term |
|---|---|
| Design History File (DHF) | Design and Development File |
| Device Master Record (DMR) | Medical Device File |
| Device History Record (DHR) | Batch records |
| Design controls per 21 CFR 820.30 | Design and development per ISO 13485 Clause 7.3 |
Key QMSR Changes Affecting Software Submissions
Design controls now reference ISO 13485 Clause 7.3. The design and development process under QMSR follows the ISO 13485 structure, which means the design control outputs you reference in a Special 510(k) should align with Clause 7.3 requirements: design and development planning (7.3.2), design inputs (7.3.3), design outputs (7.3.4), design review (7.3.5), design verification (7.3.6), design validation (7.3.7), and design and development changes (7.3.9).
Software validation under QMSR 4.1.6. QMSR incorporates the Computer Software Assurance (CSA) approach, as described in the FDA's finalized CSA guidance (September 2025). Software used in the quality system -- including development tools, test environments, and build systems -- must be validated or otherwise assured per this guidance. For Special 510(k) submissions, this means your V&V summary should reflect that the tools and environments used for verification and validation were themselves validated.
CI/CD pipelines recognized as production controls under QMSR. Continuous Integration and Continuous Deployment pipelines are treated as production and process controls. If your software build, test, and deployment pipeline is used to produce the device software that is the subject of the Special 510(k), the pipeline must be validated under QMSR. Document this in the Design and Development File.
Submission Format: Special 510(k) via eSTAR
All 510(k) submissions must now be submitted electronically using the FDA's eSTAR (Electronic Submission Template) format. For a Special 510(k) with software changes, the following approach ensures the evidence package is organized for efficient review.
eSTAR Version and Setup
- Use the current eSTAR template: Non-IVD eSTAR v6.1 (or IVD eSTAR v6.1 for in vitro diagnostic devices).
- Select "Special 510(k)" as the submission type in the cover letter section.
- Reference your own previously cleared 510(k) number as the predicate.
Section Mapping for Software Evidence
| eSTAR Section | Content for Special 510(k) -- Software/Cybersecurity |
|---|---|
| Cover Letter | State that this is a Special 510(k); describe the change in one paragraph; reference the predicate 510(k) number; state that the change was processed through design controls |
| Device Description | Brief description of the device and the specific software/cybersecurity change; version numbers before and after |
| Substantial Equivalence | Summary comparison to the predicate; focus on what changed and why the change does not raise new questions of safety or effectiveness |
| Software Documentation | IEC 62304 software lifecycle documentation summary; software level of concern; V&V summary; traceability |
| Cybersecurity Documentation | Threat model summary; SBOM; cybersecurity risk assessment; Section 524B documentation (if cyber device) |
| Performance Testing | Summary of verification and validation results; reference the design control process outputs |
| Labeling | Updated IFU or labeling excerpts reflecting the change |
| Risk Analysis | ISO 14971 risk analysis summary specific to the change |
Attachment Naming Conventions
Use clear, descriptive file names that allow the reviewer to locate specific evidence quickly:
01_CoverLetter_Special510k_K[XXXXXX].pdf02_RiskAnalysis_SoftwareChange_Summary.pdf03_SoftwareVV_Summary_IEC62304.pdf04_CybersecurityRiskAssessment_Update.pdf05_ThreatModel_Update.pdf06_SBOM_Update.csv07_TraceabilityMatrix.pdf08_Labeling_IFU_Changes.pdf
Referencing the Original Cleared Submission
In the Substantial Equivalence section, explicitly reference the original cleared 510(k) submission by its K-number. State the clearance date, the device name, and the product code. If the current submission references multiple prior clearances (for example, if earlier Special 510(k) submissions have been cleared for the same device), provide a chronology of all prior Special 510(k) clearances.
Built-in DOC Options in eSTAR
eSTAR includes pre-built Declaration of Conformity (DOC) sections for recognized consensus standards. For software changes, the relevant DOC sections include:
- IEC 62304 (software lifecycle)
- IEC 62366-1 (usability engineering)
- IEC 81001-5-1 (health software cybersecurity, if applicable)
Complete these DOC sections if the change was evaluated against these standards. The DOC replaces the need to submit the full standard compliance evidence.
Common Failure Modes and Remediation
| Failure Mode | Root Cause | Remediation | Preventive Measure |
|---|---|---|---|
| FDA converts Special to Traditional during review | Evidence package insufficient for summary review; underlying data needed | Supplement with full data; accept extended timeline | Pre-submission strategy meeting with FDA to confirm Special eligibility |
| AI request for full V&V data | V&V summary too high-level; lacks detail on test methods and acceptance criteria | Provide full test protocols and results | Include method descriptions and pass/fail criteria in the summary |
| RTA (Refuse to Accept) for missing cybersecurity documentation | Section 524B requirements not addressed for a cyber device | Submit complete cybersecurity package per FDA guidance | Use the eSTAR cybersecurity checklist before submission |
| Risk analysis does not cover cybersecurity dimensions | Software risk analysis limited to clinical hazards; cybersecurity risks treated separately or not at all | Integrate cybersecurity risk analysis into the overall ISO 14971 risk analysis | Maintain a unified risk register that includes clinical and cybersecurity hazards |
| SBOM not in required format | SBOM submitted as PDF or narrative instead of machine-readable format | Regenerate SBOM in SPDX or CycloneDX format | Automate SBOM generation in the CI/CD pipeline |
| Predicate device K-number incorrect or not the submitter's own | Referencing a competitor's clearance or a K-number that belongs to a different device | Verify predicate ownership and K-number accuracy before submission | Maintain a regulatory clearance register with all K-numbers and dates |
Risk Analysis Summary Template (Illustrative)
The following table structure illustrates the risk analysis summary that should support a Special 510(k) for a software or cybersecurity change. This is not a complete risk analysis -- it is the summary format suitable for inclusion in the submission.
| Hazard ID | Hazard Description | Risk Before Change (Severity x Probability) | Change Description | Risk Control Measure(s) | Risk After Change (Severity x Probability) | V&V Evidence | Residual Risk Acceptable? |
|---|---|---|---|---|---|---|---|
| SW-042 | Unauthorized parameter modification via unencrypted wireless channel | High (4) x Medium (3) = 12 | Enabled TLS 1.3 encryption for all wireless communication channels; deprecated legacy TLS 1.1 | Transport encryption; certificate-based authentication; message integrity verification | High (4) x Low (1) = 4 | Protocol verification test report TR-2026-017; penetration test report PT-2026-003 | Yes -- per risk acceptance criteria defined in RM Plan v3.2 |
| SW-043 | Known CVE in third-party JSON parser library (CVE-2026-XXXX) | Medium (3) x High (4) = 12 | Updated JSON parser library from v2.1.3 to v2.2.0 (patched version) | Input validation; library update; fuzz testing | Medium (3) x Very Low (1) = 3 | Regression test suite RT-2026-008 (142 test cases, 100% pass); SBOM updated | Yes |
| SW-044 | Insufficient logging of cybersecurity events hinders incident detection | Low (2) x High (4) = 8 | Added structured security event logging with tamper-evident audit trail | Audit logging; SIEM integration capability; log integrity verification | Low (2) x Medium (2) = 4 | Log integrity verification test report TR-2026-021; log volume stress test | Yes |
Each row in this summary maps back to the full risk analysis in the Risk Management File. The V&V Evidence column references specific test reports by identifier, which the FDA can request if it needs the underlying data.
Reviewer Objection Table
The following table lists common FDA reviewer objections to Special 510(k) submissions for software/cybersecurity changes and strategies to preempt them.
| Reviewer Objection | Why It Happens | Preemption Strategy |
|---|---|---|
| "The change introduces new risks that cannot be evaluated in summary format." | Risk analysis summary does not adequately demonstrate that risk controls are well-established and verifiable | Include explicit statements in the risk analysis summary identifying the verification method, the standard it aligns with, and prior instances where the same method was used for this device type |
| "The software change modifies the device's technological characteristics." | The change is characterized as a minor update but actually alters the software architecture or core algorithm | Be precise and conservative in the change description. If the architecture is materially different, file a Traditional 510(k) from the start |
| "Cybersecurity documentation is insufficient for a cyber device under Section 524B." | The submission does not include all required cybersecurity elements: SBOM, vulnerability disclosure process, update/patch plan | Use the Section 524B checklist in the FDA's cybersecurity guidance and the eSTAR cybersecurity section to verify completeness before submission |
| "The predicate device referenced is not the submitter's own device." | The manufacturer references a predecessor company's clearance or a different legal entity's K-number | Verify legal entity continuity. If the device was acquired through a corporate transaction, include documentation of the legal transfer of ownership |
| "The V&V summary does not provide sufficient detail on test methods and acceptance criteria." | Summary states "all tests passed" without describing what was tested, how, and against what criteria | Include a table of test categories, number of tests, test methods, acceptance criteria, and pass/fail results. Reference full protocols by document number |
| "Special 510(k) is not appropriate for this change because it affects clinical performance." | The change was classified as a non-clinical software update but actually modifies clinical functionality | Apply the decision tree honestly. If Node 4 triggers (clinical functionality affected), choose Traditional regardless of whether Nodes 5 and 6 might support Special |
Related Resources
- FDA eSTAR Electronic Submission Template Guide -- detailed walkthrough of the eSTAR template, section-by-section
- Medical Device Cybersecurity Guide -- comprehensive guide to FDA cybersecurity requirements, Section 524B, threat modeling, and SBOM
- FDA Cybersecurity Guidance and QMSR Update 2026 -- analysis of the February 2026 cybersecurity guidance revision and its alignment with QMSR
Key Takeaways
The decision tree is sequential and risk-based. Work through Nodes 1 through 6 in order. If any node directs you to a Traditional 510(k), stop. Do not continue to see if a later node might support Special.
Cybersecurity-only hardening usually does not require a 510(k). If the change is purely to strengthen security with no impact on device functionality, a Letter to File is appropriate. Document the rationale thoroughly.
The evidence package must be a true summary of design control outputs. The Special 510(k) is not a shortcut -- it is a different format. The underlying design control work must be just as rigorous as for a Traditional submission.
QMSR terminology matters. As of February 2, 2026, design control documentation should use ISO 13485 terminology (Design and Development File, Medical Device File) aligned with the QMSR framework.
When in doubt, file Traditional. The penalty for guessing wrong on Special eligibility is not a rejection -- it is a conversion to Traditional that costs you the 30-day review goal and triggers an AI request. If your confidence in Special eligibility is below 90%, file Traditional from the start.