Key takeaways
- A 510(k) is built around a predicate device and a substantial-equivalence argument.
- The FDA’s software documentation level (Basic vs Enhanced) sets how much firmware evidence you submit.
- Core firmware deliverables: software description, requirements, architecture, V&V, and revision history.
- Risk and traceability come from ISO 14971 and IEC 62304 — the 510(k) reuses them.
- Connected devices now also need a FDA 524B cybersecurity package in the submission.
What a 510(k) is — and what it is not
A 510(k) is a premarket submission demonstrating that your device is substantially equivalent to a legally marketed predicate — same intended use, and the same or equally safe technological characteristics. It is not a clinical-trial pathway like a PMA; it is a comparison argument backed by engineering evidence. Choosing a strong, well-matched predicate early shapes your entire firmware evidence package.
The FDA software documentation level decides your firmware workload
The FDA’s guidance on software in submissions replaced the old ‘levels of concern’ with a Documentation Level: Basic or Enhanced. Enhanced applies, broadly, when a software failure could cause serious injury or death, or for certain higher-risk device types. The level determines how much you submit, not how much you do internally.
| Documentation element | Basic | Enhanced |
|---|---|---|
| Software description & device hazard analysis | Required | Required |
| Software requirements specification | Summary | Full specification |
| Architecture / design (incl. detailed design) | Architecture overview | Architecture + detailed design |
| Verification & validation (unit, integration, system) | System-level summary | Full V&V records, including unit/integration |
| Revision history & unresolved anomalies | Required | Required, with deeper anomaly evaluation |
Map your IEC 62304 safety class to the FDA level early: a class C software item almost always lands in Enhanced, and that decision drives schedule and budget.
The firmware evidence the FDA actually reads
Software description and architecture
A clear narrative of what the firmware does, its operating environment, and a software architecture showing items, interfaces and where risk controls live. For Enhanced, add the detailed design.
Requirements and traceability
A versioned software requirements specification, each requirement traceable to design and to a passing test. Reviewers routinely sample a requirement and follow the trace — see why traceability fails audits.
Verification and validation
Documented V&V with acceptance criteria and results: unit verification, integration testing, and system-level validation against the requirements. Test logs, not just a pass/fail claim.
Hazard analysis and revision history
An ISO 14971-based hazard analysis linking software failures to risk controls, plus a complete revision history and a list of unresolved anomalies with risk justification.
Cybersecurity is now part of the 510(k)
Since the 2023 Omnibus added section 524B to the FD&C Act, a ‘cyber device’ submission must include a cybersecurity plan, a software bill of materials (SBOM), evidence of secure design, and a process for monitoring and patching post-market. For a connected firmware product this is no longer optional. Our 524B guide breaks down exactly what the package contains.
Practical sequencing
- Pick the predicate and confirm intended use match.
- Set the IEC 62304 class and the FDA Documentation Level together.
- Run the lifecycle so V&V and traceability accrue as you build, not at the end.
- Assemble the 524B cybersecurity package in parallel for connected devices.
This sequencing applies to US market entry; for Canada you pursue a Health Canada Medical Device Licence, and for the EU the MDR route — the underlying firmware evidence is largely reusable. The compliant medical IoT hub maps how the same engineering file serves North American and global submissions.
Where Fundamentum fits
A 510(k) reuses your engineering file — and a connected device must show governed updates and a secure supply of firmware. Fundamentum, our Canadian IoT platform, delivers signed firmware, governed OTA and an audit trail in a SOC 2 Type II perimeter, giving your submission concrete post-market evidence. It can interface with AWS, Azure or Google Cloud if your architecture requires it. See the platform →
Frequently asked questions
What is a predicate device in a 510(k)?
A predicate is a legally marketed device with the same intended use and equivalent technological characteristics that you compare your device against. The 510(k) argument is substantial equivalence to that predicate. Choosing a strong, well-matched predicate early shapes the entire firmware evidence package.
What software documentation does the FDA expect?
The FDA sets a Documentation Level — Basic or Enhanced. Enhanced applies broadly when a software failure could cause serious injury or death. Both require a software description, requirements, architecture, V&V and revision history; Enhanced demands full detailed design and complete unit/integration verification records.
How does IEC 62304 class map to the FDA level?
They are related but distinct. A higher IEC 62304 class (B or C) typically lands in the FDA’s Enhanced Documentation Level. Setting both together early prevents costly re-documentation if you discover late that an item is higher-risk than assumed.
Is cybersecurity required in a 510(k)?
For connected devices, yes. Since the 2023 Omnibus added section 524B, a cyber-device submission must include a cybersecurity plan, an SBOM, secure-design evidence and a post-market patching process. Missing this can trigger a refuse-to-accept decision.
Can the same file support Canada and the EU?
Largely yes. The firmware evidence — requirements, architecture, V&V, traceability, risk — is reusable across markets. Canada uses a Health Canada Medical Device Licence and the EU uses the MDR; the engineering substance carries over, and only the submission wrapper changes.
Related reading
Talk to an IoT engineer — free
Book a FREE 30-minute consultation with our team. No slides, no obligation — a working session on your connectivity, platform or compliance questions.
