Question 1

What exactly is an SPDF, and does the FDA require one?

Accepted Answer

A Secure Product Development Framework is an integrated set of processes - threat modeling, secure design, SBOM, verification, vulnerability management, and postmarket monitoring - that produces the cybersecurity evidence FDA reviewers expect. Section 524B of the FD&C Act effectively requires one for all 'cyber devices,' and the FDA's February 2026 final premarket cybersecurity guidance treats an SPDF as the primary way to satisfy those obligations. The framework is also referenced explicitly in AAMI SW96 and IEC 81001-5-1, both of which reviewers now cite by name in deficiency letters.

Question 2

What's included in your SPDF service?

Accepted Answer

All eight pillars: SPDF process design embedded in your QMS, STRIDE threat modeling with multi-patient and updateability views, security architecture documentation, SBOM generation and SOUP management, verification and validation testing across device / cloud / mobile / BLE / DICOM / HL7 / FHIR, Section 524B submission documentation, regulatory mapping for FDA / EU MDR / Health Canada / PMDA, and continuous postmarket monitoring via GoatWatch. Each pillar produces specific artifacts that map directly to eSTAR or PMA modular content.

Question 3

Which submission pathways do you support?

Accepted Answer

510(k), De Novo, PMA, IDE, HDE, and pre-submissions (Q-Subs). We tailor the depth of artifacts to your pathway, device class, intended use, and connectivity profile - so a Class II non-connected SaMD doesn't carry the same overhead as a Class III connected implantable. For IDE submissions we focus on the cybersecurity risks that could affect study-subject safety; for PMA we deliver the full SPDF artifact set in PMA modular format with traceability into the device master record.

Question 4

How is your SPDF service different from other approaches?

Accepted Answer

12+ years exclusively in MedTech, FDA Section 524B and February 2026 guidance alignment built in from day one, full AAMI SW96 / IEC 81001-5-1 coverage, hands-on testing of medical-device-specific protocols (DICOM, HL7, FHIR, BLE, MQTT for IoMT), continuous SBOM monitoring via GoatWatch, fixed-fee pricing with no hourly billing, unlimited retests until reviewers are satisfied, US-based senior team on every engagement, and a written Cybersecurity Deficiency Commitment that puts our fee at risk if a deficiency lands on work we delivered.

Question 5

What does an SPDF engagement cost?

Accepted Answer

Fixed-fee, scoped to your device. We deliver a written scope, deliverables list, milestone schedule, and timeline within 24 hours of the discovery call - no hourly billing, no change orders for 'unexpected complexity,' and no surprise retest fees. Pricing depends on device class, connectivity profile, number of interfaces, and how much existing documentation we can build on. Most engagements fall in a tight, predictable range; the scoping call gives you the exact number before you commit.

Question 6

How quickly can you start?

Accepted Answer

Most cybersecurity vendors put you in a 4-to-8-week onboarding queue. We start this week: 30-minute discovery call, 24-hour scoped fixed-fee quote, kickoff within days. The senior practitioner who scopes the work is the one who runs it. Junior engineers contribute under that senior lead, and every FDA-facing artifact is senior-reviewed. If your FDA submission deadline is tight or you're already inside a 180-day deficiency response window, we can compress further with parallel workstreams.

Question 7

How long does an SPDF build take?

Accepted Answer

Typical engagements run 6-14 weeks depending on device complexity, connectivity, and how much existing documentation we can build on. A Class II SaMD with limited interfaces often finishes in 6-8 weeks; a Class III connected implantable with cloud back-end, mobile app, and OTA updates runs closer to 12-14. The timeline is fixed in writing at scoping, with milestone checkpoints and weekly status updates so your regulatory and engineering leads always know where the work stands.

Question 8

What if the FDA still issues a cybersecurity deficiency?

Accepted Answer

Our written Cybersecurity Deficiency Commitment: if FDA returns a cybersecurity deficiency on work we delivered, we remediate it at no additional cost until it's resolved - including any additional testing, documentation rework, threat model updates, or response narrative the reviewer asks for. (FDA clearance decisions remain with the agency; we commit to the cybersecurity workstream, not the overall clearance outcome.) In practice, our deficiency rate on submitted SPDF packages is effectively zero across 250+ devices.

Question 9

Do you align to the QMSR, AAMI SW96, and IEC 81001-5-1?

Accepted Answer

Yes. The SPDF is built to integrate with the QMSR (21 CFR Part 820 / ISO 13485:2016), and every artifact maps to the consensus standards FDA increasingly references in deficiency letters: AAMI SW96, AAMI TIR57, AAMI TIR97, IEC 81001-5-1, IEC 62304, ISO 14971, MDCG 2019-16, NIST SP 800-115, and UL 2900-2-1. The mapping is documented explicitly in the package so your reviewer can trace each requirement to the standard, the artifact that satisfies it, and the test that validates it.

Question 10

What deliverables do we receive?

Accepted Answer

Cybersecurity Risk Management Report, Cybersecurity Management Plan, threat model with data flow diagrams and threat trees, the four required architecture views, SBOM in SPDX or CycloneDX format with SOUP analysis and VEX statements, penetration and fuzz test reports, secure-boot and OTA validation evidence, cybersecurity labeling for the IFU, postmarket monitoring plan, vulnerability disclosure policy, and a complete traceability matrix - all eSTAR-formatted, version-controlled, and reviewer-ready.

Build an SPDF the FDA Actually Accepts.

FDA cybersecurity requirements just got tougher

Months of delay, millions lost

RTAs & deficiency letters

Patient safety & liability

The eight pillars of an FDA-ready SPDF

Process & lifecycle

Software supply chain

Verification & testing

Submission documentation

Design-time decisions that lock in cybersecurity posture

From first call to FDA-ready in 4 steps

1 · Discovery call (30 minutes)

2 · SPDF gap assessment (within 24 hours)

3 · SPDF build & integration (starts in days)

4 · FDA-ready submission package

Reviewer-ready deliverables in one engagement

Public premarket cybersecurity history

Section 524B(b)(2) updateability as design-input

SPDF frequently asked questions

Secure by design - baked into the SDLC, not bolted on at V&V.