Question 1

What does Blue Goat Cyber specialize in?

Accepted Answer

Blue Goat Cyber is a medical device cybersecurity firm. That is the only thing we do. Every engineer, every report template, every piece of internal training is built around getting connected medical devices through FDA review and keeping them safe in the field. On the premarket side that means threat models, security risk assessments, SBOMs with VEX, architecture views, SAST and SCA, and manual penetration testing, all formatted to drop straight into an eSTAR 510(k), De Novo, or PMA submission.

Question 2

Why is the company called Blue Goat Cyber?

Accepted Answer

Founder Christian Espinosa named the company after his experience as an avid mountain climber, including climbing the Seven Summits. Mountain goats are the animal he watched move calmly across terrain that defeats almost everything else, sheer rock faces, exposed ridgelines, weather that turns in minutes.

Question 3

Who are your services designed for?

Accepted Answer

We exclusively serve medical device manufacturers, startups preparing their first 510(k), mid-sized companies expanding a product family, and global market leaders managing portfolios of dozens of cleared devices. Within those companies our typical points of contact are VPs of Engineering, Heads of Regulatory Affairs, Heads of Quality, CISOs, and product cybersecurity leads.

Question 4

What is your commitment?

Accepted Answer

We back every premarket cybersecurity engagement with a no-cost deficiency resolution commitment. The promise is concrete: if your FDA submission is held up by a cybersecurity-related deficiency on work that we delivered, we resolve it at no additional cost until the submission is approved.

Question 5

What sets you apart?

Accepted Answer

Three things. First, exclusive focus on medical device cybersecurity, every engineer in the practice has spent years on this regulatory context, not just generic application security or enterprise red teaming. That shows up in tiny details a generalist will miss: how a threat model traces back to ISO 14971 risk controls, how an SBOM is structured so a reviewer can ingest it, how a pen test report distinguishes intended-use risk from theoretical exposure.

Question 6

What types of devices do you work with?

Accepted Answer

We work across the full range of connected medical devices, including in-vitro diagnostics (IVD) and lab platforms, wearables and remote patient monitoring (RPM) devices, implantables such as cardiac implantable electronic devices (CIEDs) and neurostimulators, robotic surgical systems and computer-assisted surgical platforms, Software as a Medical Device (SaMD) including AI/ML-enabled imaging and decision support, digital therapeutics (DTx), infusion pumps, drug-delivery devices and combination products, continuous glucose monitors and insulin pumps, dental and orthopedic devices with digital components, and legacy devices being modernized to current FDA cybersecurity expectations.

Question 7

What certifications does your team hold?

Accepted Answer

Our engineers hold a combination of offensive security, secure-development, and assurance certifications, including CISSP (Certified Information Systems Security Professional), CSSLP (Certified Secure Software Lifecycle Professional), OSWE (Offensive Security Web Expert), CRTE (Certified Red Team Expert), CARTP (Certified Azure Red Team Professional), OSCP, GPEN, and others.

Question 8

How many FDA submissions has your team supported?

Accepted Answer

Our team has contributed cybersecurity documentation, threat models, SBOMs, VEX statements, security risk assessments, architecture views, and penetration test reports for 275+ devices across the 510(k), De Novo, PMA, and IDE pathways. That includes original submissions, special and abbreviated 510(k)s, real-world evidence supplements, and a substantial volume of FDA deficiency response packages.

Question 9

Do you sign NDAs and BAAs before engaging?

Accepted Answer

Yes. We routinely sign mutual non-disclosure agreements, master services agreements, and Business Associate Agreements (BAAs) before receiving any device, source code, firmware, design documentation, or protected health information (PHI). For most prospects we can return a signed mutual NDA within 24 hours, often the same business day if the language is standard.

Question 10

What is FDA Section 524B and who does it apply to?

Accepted Answer

' A cyber device is defined as a device that (1) includes software validated, installed, or authorized by the sponsor, (2) has the ability to connect to the internet, and (3) contains technological characteristics that could be vulnerable to cybersecurity threats. In practice that captures the overwhelming majority of connected medical devices on the market today, including any device that exposes a wireless interface, any companion mobile or web app, and any device that pushes data to a cloud back-end.

Question 11

What changed with the FDA's February 3, 2026 final guidance?

Accepted Answer

The FDA's February 3, 2026 final guidance, 'Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions,' supersedes the June 2025 final guidance (which had itself superseded the September 2023 final) and is the FDA's current thinking on what a cyber device submission must contain.

Question 12

What is a Secure Product Development Framework (SPDF)?

Accepted Answer

A Secure Product Development Framework (SPDF) is a documented set of processes that integrates cybersecurity activities across the entire product lifecycle, from concept through design, development, verification, release, deployment, and postmarket.

Question 13

Do I need a separate cybersecurity submission for an eSTAR 510(k)?

Accepted Answer

No, there is no separate cybersecurity submission. Cybersecurity artifacts are embedded directly inside the eSTAR template, which has dedicated sections that map to the 2026 guidance expectations. Specifically, the eSTAR cybersecurity section asks for a security risk assessment, threat model, SBOM, vulnerability assessment, architecture views, security testing summary (including penetration testing), interoperability considerations, and labeling content (cybersecurity bill of materials disclosed in user documentation).

Question 14

Does Section 524B apply to my device if it does not connect to the internet?

Accepted Answer

Maybe. The Section 524B definition of 'cyber device' has three prongs: the device includes sponsor-validated software, it has the ability to connect to the internet, and it contains technological characteristics that could be vulnerable to cybersecurity threats. All three must be true. The trap is the second prong, which is broader than it sounds.

Question 15

What SBOM format does the FDA accept?

Accepted Answer

4 or later. Both formats are explicitly endorsed in the 2026 final guidance and in ANSI/AAMI SW96. 5 in JSON because it has first-class support for VEX (Vulnerability Exploitability eXchange) statements, component pedigree, and cryptographic hashes, and is the format we have seen reviewers most comfortable ingesting.

Question 16

Do you generate SBOMs for firmware and embedded devices?

Accepted Answer

Yes, and this is one of the harder problems in medical device SBOM work, because most build-time SCA tools were designed for cloud applications and miss large portions of an embedded stack. For firmware and RTOS-based devices we combine three techniques. First, build-time SCA against the source tree, package manifests (CMake, Conan, vcpkg, Yocto recipes, Buildroot manifests), and dependency lockfiles to capture first-class dependencies with full version metadata.

Question 17

How do you handle CVEs that show up after submission?

Accepted Answer

We use VEX (Vulnerability Exploitability eXchange) statements, which are the FDA-preferred way to manage the noise generated by continuous CVE scanning against any non-trivial SBOM.

Question 18

Should I choose SPDX or CycloneDX for my SBOM?

Accepted Answer

5+ in JSON. The reason is operational rather than regulatory. CycloneDX has first-class native support for VEX statements embedded inside the SBOM itself, which means your vulnerability triage travels with the component inventory in a single document. 3 supports VEX through external references and is fully valid, but the tooling ecosystem around CycloneDX for medical device use cases (vulnerability intelligence platforms, hospital procurement portals, FDA-facing automation) tends to be a step ahead.

Question 19

What threat modeling methodology do you use?

Accepted Answer

Our default methodology is STRIDE-per-element, applied to a data flow diagram (DFD) of the device's architecture, and supplemented by attack trees for the highest-risk flows and use cases. STRIDE, Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, Elevation of privilege, gives us a systematic way to enumerate threats against every element (process, data store, data flow, external entity) in the architecture, which is exactly the kind of decomposition reviewers under the 2026 FDA guidance want to see.

Question 20

What does a medical device penetration test actually cover?

Accepted Answer

A real medical device pen test covers every realistic attack surface, exercised by humans, against the device in its intended-use configuration. Hardware: USB, serial (UART, JTAG, SWD), debug headers, BLE/Bluetooth Classic, Wi-Fi, cellular (LTE/NB-IoT), NFC, optical and inductive interfaces. Firmware: extraction (chip-off, JTAG, bootloader exploitation, glitching), reverse engineering, secure-boot bypass attempts, OTA update integrity, and binary analysis for hardcoded credentials or weak crypto.

Question 21

Is automated scanning enough for FDA submissions?

Accepted Answer

No. The FDA's 2026 guidance is explicit that vulnerability scanning alone, Nessus, Qualys, Burp Active Scan, OWASP ZAP, npm audit, does not satisfy the expectation for security testing. Reviewers want evidence of manual, exploit-driven testing performed by qualified humans with access to the device, source code, and design documentation.

Question 22

Do you offer free retesting after we fix findings?

Accepted Answer

Yes. Every premarket penetration test we deliver includes one round of remediation retest at no additional cost. After your engineering team fixes the findings from the original test, our testers re-execute the relevant attack scenarios against the patched device or build, validate that each fix actually closes the vulnerability (and does not just hide it from a scanner), and update the report so the version delivered to the FDA shows resolved findings rather than open ones.

Question 23

What does an FDA-aligned postmarket program look like?

Accepted Answer

An FDA-aligned postmarket cybersecurity program has five core components, each producing objective evidence the FDA can review under the FDA's postmarket cybersecurity guidance. First, continuous SBOM and CVE monitoring, your SBOM is loaded into a vulnerability intelligence platform, scanned daily against NVD, GitHub Security Advisories, and vendor PSIRT feeds, with VEX triage performed weekly so the working set is real and not theoretical.

Question 24

Can you bring a legacy device into compliance?

Accepted Answer

Yes, legacy device modernization is a substantial portion of our postmarket practice, because many devices currently on the market were cleared under earlier guidance and lack the artifacts the FDA now expects when supplements, software changes, or significant updates are filed. Our process starts with a gap assessment against current FDA expectations (2026 premarket guidance, 2016 postmarket guidance, ANSI/AAMI SW96, AAMI TIR57/97), benchmarked against the artifacts you currently have.

Question 25

How do you handle EU MDR and the Cyber Resilience Act?

Accepted Answer

Our deliverables are designed so a single engagement satisfies FDA, EU MDR, Health Canada, TGA, PMDA, and IMDRF expectations rather than requiring parallel cybersecurity workstreams for each market. ' We align lifecycle process documentation to IEC 81001-5-1 (health software lifecycle security) and IEC TR 60601-4-5 where applicable.

Question 26

What patch cadence does the FDA actually expect for deployed devices?

Accepted Answer

The FDA's postmarket cybersecurity guidance does not prescribe a single calendar, but reviewers and field investigators expect a documented, severity-tiered cadence that you actually meet. In practice the cadences we recommend and have seen accepted are: critical vulnerabilities (active exploitation or direct path to patient harm) patched and shipped within 30 days of confirmation, high-severity within 60-90 days, medium within the next regular release cycle (typically 6 months), and low handled as documentation-only or rolled into routine maintenance.

Question 27

When does the EU Cyber Resilience Act start applying to my medical device?

Accepted Answer

The Cyber Resilience Act entered into force in December 2024, with the core obligations on manufacturers (vulnerability handling, incident reporting, essential cybersecurity requirements, conformity assessment, CE marking for digital elements) becoming applicable in stages culminating in full applicability on December 11, 2027. The vulnerability and incident reporting obligations to ENISA become applicable earlier, in September 2026.

Question 28

Do you support AI/ML-enabled SaMD specifically?

Accepted Answer

Yes, AI/ML-enabled SaMD is one of our fastest-growing service areas, because the threat surface differs meaningfully from traditional rule-based software and the FDA's PCCP (Predetermined Change Control Plan) framework, AI/ML-enabled device guidance, and the 2026 premarket cybersecurity guidance interact in ways that catch teams off-guard.

Question 29

What premarket services do you offer?

Accepted Answer

Our premarket portfolio covers the full set of cybersecurity artifacts a Section 524B cyber device submission requires under the 2026 FDA final guidance.

Question 30

Why is penetration testing critical?

Accepted Answer

Penetration testing is critical for two reasons, one regulatory and one operational. Regulatory: the FDA's 2026 final guidance explicitly expects evidence of manual, exploit-driven security testing against connected medical devices, and reviewers will issue deficiency letters when a submission's security testing section consists only of automated scanner output.

Question 31

What is SBOM management?

Accepted Answer

SBOM management is the lifecycle process of generating, maintaining, distributing, and acting on Software Bills of Materials across your product. Generation produces a complete, accurate, machine-readable inventory of every software component in your device, first-party code, third-party libraries, OS components, bootloader, and (for connected ecosystems) companion app and cloud back-end SBOMs.

Question 32

How do you handle FDA deficiencies?

Accepted Answer

FDA cybersecurity deficiencies are time-sensitive, every week a submission sits in deficiency status is a week off your launch, so our process is built for speed without losing technical defensibility.

Question 33

How fast can you respond to an FDA deficiency letter?

Accepted Answer

We typically deliver a complete cybersecurity deficiency response package within 2-4 weeks of receiving the deficiency letter and the underlying source materials (current submission artifacts, device or firmware build, source code if needed, and prior threat model and SBOM).

Question 34

What postmarket services do you provide?

Accepted Answer

Our postmarket services keep cleared devices compliant and patients safe through the entire deployed lifecycle. Continuous SBOM and CVE monitoring with weekly VEX triage so your working list of vulnerabilities is real and not theoretical. txt, intake email, researcher acknowledgment workflow, and (for managed-service customers) handling of incoming reports on your behalf.

Question 35

Why is postmarket cybersecurity important?

Accepted Answer

Postmarket cybersecurity is important because the threat environment evolves continuously after FDA clearance, and the regulatory framework explicitly holds you responsible for that evolution. New vulnerabilities are disclosed against the libraries and OS components in your device every week (NVD alone publishes thousands of CVEs annually).

Question 36

Can you secure devices used globally?

Accepted Answer

Yes, global market deployment is the norm rather than the exception for our customers, so our deliverables are designed to satisfy multiple regulatory regimes from a single engagement. 2 with MDCG 2019-16, the EU Cyber Resilience Act essential requirements, Health Canada cybersecurity guidance, TGA medical device cybersecurity guidance, PMDA pre/post-market expectations, and IMDRF principles and practices.

Question 37

How much does an FDA penetration test cost?

Accepted Answer

For a simple device with a reasonable turnaround time and no travel, our FDA penetration tests typically start around $15,000. Price rises with the number of interfaces, radios, cloud and mobile components, travel, and retest scope. We give a fixed-fee quote after a short scoping call, and our cost article at /blog/medical-device-cybersecurity-cost breaks down the drivers in detail.

Question 38

What happens after we sign a pen test contract?

Accepted Answer

Every project gets an assigned project manager and a kickoff call. We set up a shared Slack channel and secure file shares, then run intake: we need your IFU, software architecture document, hazard analysis, and threat model (we can build the threat model if you do not have one).

Question 39

Is there a free way to check our FDA cybersecurity readiness?

Accepted Answer

Yes. Our free readiness check at /readiness asks seven questions about your device and documentation and returns a readiness score with a gap list mapped to Section 524B and the FDA's February 3, 2026 premarket guidance. It takes about five minutes and is a good starting point before a scoping call.

Question 40

Can you review an FDA cybersecurity deficiency letter?

Accepted Answer

Yes. Our free deficiency-letter triage tool at /tools/deficiency-letter-triage helps you sort each deficiency by type and urgency. For a deeper answer, we offer a paid 48-hour gap analysis that maps every deficiency to the evidence the FDA reviewer expects and outlines a response plan before your deadline.

Question 41

Does Section 524B apply to IDE devices?

Accepted Answer

No. Section 524B(a) covers marketing submissions: 510(k), De Novo, PMA, PDP, and HDE. An Investigational Device Exemption is not a 524B pathway. However, the FDA's February 3, 2026 premarket guidance still recommends cybersecurity information for IDE submissions, so investigational devices should still show a threat model, risk assessment, and basic security controls.

Question 42

How do I get started?

Accepted Answer

Getting started is a single step: schedule a free 30-minute Discovery Session with our team. The session is a working call, not a sales pitch, we use the time to understand your device (intended use, connectivity model, regulatory pathway, where you are in the development lifecycle), identify the specific cybersecurity artifacts your submission will require, surface the highest-risk gaps in your current plan, and recommend a path forward whether or not it involves us doing the work.

Question 43

How much do your services cost?

Accepted Answer

We use transparent, fixed-fee pricing scoped to device complexity and specific deliverables, not hourly billing. The fixed-fee model exists because cybersecurity engagements with hourly meters create the wrong incentives: they reward extensive scope creep, they make budgeting impossible for the customer, and they put the financial risk of mis-scoping on the customer instead of the vendor.

Question 44

How long do projects take?

Accepted Answer

Most premarket projects complete within 4-8 weeks from kickoff to final deliverable. A standalone penetration test on a single connected device with companion app and cloud back-end typically runs 3-5 weeks (kickoff and scoping, 2-3 weeks of active testing, draft report, remediation retest, final report).

Question 45

How quickly can you start?

Accepted Answer

We typically begin engagements within 1-2 weeks of contract signature, and faster when the situation requires it. The week-of-kickoff sequence is straightforward: NDA executed (often before the SOW is signed); SOW finalized; data-handling and access plan agreed (where source code lives, how the device gets to us, who the engineering points of contact are); kickoff call to align on scope, deliverables, schedule, and communication cadence; and active work begins.

Question 46

Who actually does the work - employees or subcontractors?

Accepted Answer

All testing, threat modeling, SBOM generation, security risk assessment, and documentation work is performed by Blue Goat Cyber W-2 employees and a small number of vetted long-term partners under our direct supervision and on our infrastructure. We do not offshore deliverables to anonymous contractors and we do not use marketplace platforms (Upwork, Toptal-style) for any client-facing work.

Question 47

How do you protect our IP and source code?

Accepted Answer

Source code, firmware images, design documentation, and physical devices are handled in isolated, encrypted environments with access strictly limited to the named engineers on your engagement.

Question 48

Can you work under our quality management system?

Accepted Answer

Yes. We routinely operate as an external supplier under ISO 13485 quality management system arrangements and are comfortable working under your QMS rather than imposing ours.

Common questions about our work.

About Blue Goat Cyber

FDA Section 524B & 2026 Premarket Guidance

SBOMs & Supply Chain

Threat Modeling & Pen Testing

Postmarket, Legacy, & Global

Premarket Services

Postmarket Services

Pen Test Pricing, Process, & Free Tools

Working with Us

Get FDA cleared without the cybersecurity headaches.