Full-Service Cybersecurity for PMA Submissions

Talk to a MedTech cybersecurity expert

Why PMA cybersecurity is different

Class III devices supported by a PMA submission are by definition higher-risk: implants, life-sustaining therapy, novel diagnostics. The cybersecurity package follows: deeper documentation, full design history file traceability, and frequent cross-review with non-cyber FDA reviewers (risk management, human factors, sometimes biocompatibility for implants with telemetry hardware).

What full-service covers

• Threat modeling - four architecture views, STRIDE per element, AAMI TIR57/SW96 alignment, ISO 14971 traceability.
• Security risk assessment - integrated with the ISO 14971 risk file, not parallel to it.
• SBOM - CycloneDX/SPDX with VEX, postmarket maintenance plan included.
• Penetration testing - full attack surface, white-box, Letter of Attestation, retest of high/critical.
• Cybersecurity labeling - patient-facing and clinician-facing security information.
• Postmarket cybersecurity management plan - monitoring cadence, vulnerability triage SLA, patch deployment.
• Coordinated vulnerability disclosure program - intake, triage SLA, public policy.
• eSTAR / PMA modular content - section drafting in the format reviewers expect.
• AI letter response - if a deficiency comes, you do not start a new vendor search.
• Cross-discipline integration - we sit in design reviews, risk reviews, and human-factors reviews so the cybersecurity narrative is consistent across the submission.

Typical engagement timeline

Weeks 1-3: Discovery and architecture intake

Discovery call, scope confirmation, fixed-fee agreement. Architecture intake produces the four views in draft and a kickoff threat model.

Weeks 4-8: Threat modeling and security architecture

STRIDE workshops, control catalog, traceability matrix. Integrated with ISO 14971 risk file in parallel.

Weeks 6-12: SBOM, pen testing, labeling (parallel)

SBOM tooling stood up in CI, pen testing across full attack surface, cybersecurity labeling drafted with regulatory and clinical input.

Weeks 12-16: Postmarket and CVD

Postmarket plan, CVD program documents, vulnerability monitoring tooling, triage SLA, patch deployment process.

Weeks 16-20: Package assembly

PMA modular content drafted, traceability matrix completed, reviewer-eye read-through, package finalized for upload.

Weeks 20-22+: Pre-submission Q&A support

Pre-submission meeting prep, optional reviewer engagement support.

How fixed-fee works for PMA

After discovery, you receive one fixed fee covering all of the above with milestone-based payments. The fee covers AI-letter response within scope (typical case) at no additional cost. New attack surface introduced mid-engagement (e.g., a new mobile app added) is an explicit change order with a separate fee, not a hidden adjustment.

Why one team beats four vendors

• Threat model authors and pen testers share one understanding of the system - findings trace to threat-model entries automatically.
• SBOM, pen test, and threat model use consistent component naming - no reviewer confusion.
• Cybersecurity labeling is written by people who know the threat model, not handed to a marketing writer.
• AI letter responses do not require re-onboarding a vendor against the original package.
• Postmarket plan inherits the threat model and SBOM tooling already in place at clearance.

Frequently asked questions

How is PMA cybersecurity scope different from 510(k)?

Do you support modular PMA submissions?

Can you co-sit in our design reviews?

What does "full-service" actually include vs an a-la-carte engagement?

How do you handle PMA supplements?

Do you work with our existing regulatory consultant?

What is the typical fixed-fee range for PMA full-service?

Can you accelerate for an urgent PMA timeline?

Do you handle cybersecurity for combination products?

What if our PMA includes an AI/ML component?

What PMA reviewers examine that 510(k) reviewers often do not

The artifact list for a Class III package looks similar to a 510(k) list. The depth expectation does not.

• Design controls, inspected. PMA review can be accompanied by a facility inspection. Cybersecurity artifacts produced outside the QMS, on a consultant's template, with no design review records behind them, create a finding even when the technical content is strong. Every deliverable should have a corresponding design review, approval, and DHF entry.
• Manufacturing and supply chain. How firmware is signed, where signing keys live, who can authorize a production build, and how a device is provisioned with credentials at manufacture. This is rarely probed in a 510(k) and routinely probed in a PMA.
• Clinical context in the harm analysis. Class III devices sustain life or present significant risk, so the security risk assessment has to reason about clinical consequences with the same seriousness as the safety risk file, and the two files must agree.
• Lifecycle commitments. Support duration, update mechanism availability over that duration, and what happens to fielded devices when a component reaches end of support. A vague answer here is a real problem for an implantable or a life-sustaining system.

Where multi-vendor packages break

Teams that split the work across a threat-modeling consultant, a pen-testing firm, and a regulatory writer usually produce three internally coherent documents that do not agree with each other. The specific failures we are asked to repair:

• Pen test scope derived from a product description rather than the threat model, so tested surfaces and enumerated threats do not correspond.
• Two risk scoring methods in one package, because the security consultant used CVSS and the regulatory writer mapped to the ISO 14971 file differently.
• Controls listed in the architecture document that never appear in the threat model as mitigations for anything.
• A postmarket plan written by a fourth party that names an intake process the engineering team has never operated.

None of these are technical failures. They are integration failures, and they consume review cycles.

Questions worth taking to a Q-Sub

For a Class III device, a pre-submission is usually worth the calendar time. The cybersecurity questions that return the most value are narrow and decision-shaped: whether the proposed penetration testing scope and independence arrangement are acceptable, whether the security risk scoring approach and its relationship to the ISO 14971 file is agreeable, whether the proposed support duration and update mechanism meet expectations for the device type, and whether a planned PCCP's cybersecurity modifications are appropriately bounded. Getting a documented position on those four before you build the package is cheaper than negotiating them in a deficiency response. See Q-Sub vs Pre-Sub.

Where to go next

A PMA cybersecurity package is not a larger 510(k) package. It is a different kind of argument. In a 510(k) you are showing that your controls are adequate for a device substantially equivalent to something already on the market. In a PMA you are building a safety and effectiveness case from first principles, and the cybersecurity evidence has to sit inside that case rather than beside it. That changes sequencing more than it changes content.

Work backwards from the panel and the review clock. If your filing target is twelve months out, the threat model needs to be stable by month four, because everything downstream cites it. Penetration testing findings that force an architecture change in month ten are the single most expensive failure mode in a PMA program, and they are almost always traceable to a threat model that was written after the design freeze instead of before it.

Sequence the artifacts in dependency order. Architecture and data flow documentation first, because the threat model cannot be scoped without it. Threat model next, feeding the security risk assessment that ties each threat to a clinical harm under ISO 14971 and ANSI/AAMI SW96:2023. The SBOM runs in parallel on the engineering side. Penetration testing comes after the threat model, scoped from it, so the test report can be read as a verification of specific claims rather than a generic assessment. Labeling and the security documentation for users comes last and pulls from all of the above.

Use a Q-Sub deliberately. PMA reviewers will tell you whether your proposed testing depth and your harm taxonomy are acceptable, and a written answer months before filing is worth more than any internal debate. Bring specific questions with your proposed approach attached, not open-ended ones.

Finally, decide early whether one vendor owns the whole package or several own pieces. Split packages fail at the seams: the pen test scope does not match the threat model boundaries, the SBOM version does not match the tested build, and the risk assessment cites threat IDs that no longer exist. If you do split the work, one named person on your side has to own cross-artifact traceability.

• FDA Premarket Cybersecurity Service - the full cross-traceable package built as one engagement, sequenced against your filing date.
• Threat Modeling Service - the artifact everything else in a PMA package cites, delivered early enough to still influence architecture.
• FDA-Compliant SBOM Service - component inventory, support status, and VEX, built from your actual build pipeline.
• Medical Device Penetration Testing - manual testing scoped from your threat model so the report verifies your specific claims.