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. On the postmarket side it means continuous SBOM/CVE monitoring, coordinated vulnerability disclosure programs, patch validation cadence, and incident response playbooks aligned to the FDA's reporting expectations. We also handle global expansion (EU MDR, Health Canada, TGA, PMDA) and the unglamorous work of remediating legacy devices that were cleared before cybersecurity was a serious review topic. We do not do general IT cybersecurity, SOC 2, or enterprise red teaming. That focus is the entire point, when a reviewer challenges a claim in your submission, the engineer who wrote it has answered that exact question on dozens of prior devices in the same product class. The narrowness is intentional, it is what allows our deliverables to land cleanly with FDA reviewers, EU notified bodies, and your own internal quality team without needing translation, rewriting, or escalation. It also means the engineer who answers your questions on a Tuesday call has personally produced the same artifact, on a similar device, multiple times before, so the answer you get is calibrated by reality, not theory.

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. They represent resilience, focus, and a refusal to take shortcuts. Blue is the color of trust, clarity, and limitless potential, and it shows up in the alpine sky at the moments when you most want to keep climbing. The name is meant as a reminder of how we want to engage with clients. Medical device cybersecurity is genuinely difficult terrain: the regulatory expectations change, the technology stack spans firmware to cloud, and a missed deficiency can delay a clearance by months and cost a company a launch window. We promise to move across that terrain calmly, deliberately, and with the kind of footing that comes from having done it many times before. The name is also a small filter, companies looking for the cheapest possible compliance checkbox tend to self-select out, and we end up working with teams that care about getting it right the first time. Customers tell us the name sticks for the same reason it appealed to our founder, it sets a clear expectation about how the work will be done. Less swagger, more steady footing. We would rather be the firm a regulatory affairs leader recommends quietly to a peer than the one whose marketing arrives faster than its deliverables.

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. We do not work with hospitals, payers, generic SaaS companies, or non-medical IoT manufacturers, even when their technical stack looks similar, the regulatory context is different enough that a generalist firm will produce documentation a reviewer can spot from across the room. Within MedTech we cover the full product lifecycle: pre-design strategy, design-phase threat modeling, verification-phase pen testing, submission support, FDA deficiency response, and postmarket monitoring. Device categories include Class II and Class III implantables, wearables, in-vitro diagnostics, robotic surgical systems, infusion and drug delivery, neurotech, imaging and AI-enabled SaMD, digital therapeutics, and connected diagnostic platforms. If your product touches a patient (directly or through a clinical decision) and connects to anything, another device, a phone, a cloud, or a hospital network, you are in our wheelhouse. Across all of those device categories the common thread is regulated, patient-impacting connectivity. If your product is being prepared for an FDA submission, an EU MDR conformity assessment, or postmarket monitoring under the 2025 FDA postmarket guidance, you are exactly the customer we are built for, and our deliverables will read as native rather than retrofitted.

Question 4

What is your guarantee?

Accepted Answer

We back every premarket cybersecurity engagement with a 100% success guarantee. 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. That includes rewriting documentation, re-running tests, generating new evidence, drafting the deficiency response, and supporting any follow-up reviewer questions, for as many rounds as it takes. The reason we can offer this is that we own the entire cybersecurity package end to end and we calibrate it against the bar real reviewers are applying right now, not the bar from two years ago. We also stay in close touch with how FDA review divisions are interpreting the 2026 guidance, ANSI/AAMI SW96, and the eSTAR cybersecurity sections, and we update internal templates the moment we see a new deficiency pattern. The guarantee is not legal sleight of hand. It is the natural consequence of a focused practice: we have seen the patterns, we know what triggers an information request, and we would rather absorb the cost of a re-test than ship work we are not confident will clear review. The practical effect is that risk transfers from your regulatory budget to ours, which is the right place for it: we are the experts being paid for the outcome, not just the activity. Customers tell us this single contractual line is one of the main reasons they choose us over generalist firms that charge less but offer no equivalent commitment.

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. Second, a real understanding of the FDA's 2026 premarket cybersecurity final guidance, ANSI/AAMI SW96, AAMI TIR57, AAMI TIR97, IEC 81001-5-1, ISO 13485, and ISO 14971, not as a reading-list, but as the operational basis for how we structure deliverables. Third, a track record. Our team has supported 250+ FDA submissions across 510(k), De Novo, PMA, and IDE pathways. Every report we produce is calibrated by the patterns of what reviewers actually challenge, not by what a textbook says they should. The combination is what allows us to back our work with a 100% success guarantee. A generalist firm cannot make that promise honestly. We can, because we have already encountered most of the failure modes. The honest test is to compare a sample chapter side by side with a generalist's deliverable. The structure, the citations, the level of regulatory specificity, and the way findings trace into ISO 14971 risk controls all read differently. We are happy to share redacted samples during scoping so the comparison is concrete rather than abstract.

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. Each of these categories has its own engineering reality. Surgical robotics centers on real-time control loops and ROS-based stacks. Implantables center on telemetry security and battery-aware crypto. CGMs center on BLE pairing and the mobile app boundary. Imaging AI centers on DICOM, model integrity, and cloud APIs. Because we have seen these patterns repeatedly, we calibrate threat models, pen test scope, and SBOM coverage to what actually matters for that product class, instead of running a one-size-fits-all checklist that wastes engineering time and still fails to address the risks reviewers care about. If your device is not in the list above but fits the broader pattern of regulated, patient-impacting, connected technology, ask anyway. Roughly a third of our engagements involve a product class slightly outside the obvious list, and the underlying engineering disciplines transfer cleanly. The Discovery Session is where we confirm fit before any commitment is made on either side.

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. Several team members are former US military and government red team operators with active background investigations, which matters when devices are reviewed in the context of national-security-adjacent supply chains. Beyond paper credentials, the more useful qualification is direct experience. Our pen testers have personally extracted firmware from RTOS-based pumps, defeated secure-boot implementations on imaging devices, found SQL injection in cloud APIs serving CGM data, and demonstrated denial-of-service against teleoperation channels in surgical robotic prototypes. Our regulatory writers have personally drafted threat models, security risk assessments, and SBOM/VEX packages that have been accepted by FDA reviewers without follow-up questions. Certifications are a useful filter; production work history is the real one. We disclose lead engineer profiles on request when scoping engagements so you can verify the people who will actually do your work, not just the firm's brochure. We also publish lead-engineer biographies on request and are comfortable with customers interviewing the specific engineers who will work the engagement before signing the SOW. Asking that question is healthy, and a useful filter against firms whose senior credentials sit in a brochure while the actual work is delivered by someone you never meet.

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 to 250+ FDA submissions 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. The breakdown by pathway, device class, and review division is published on our /proof page so prospects can verify the depth of experience in the specific product family they are working in. The number is meaningful for two reasons. First, it represents thousands of reviewer comments, deficiencies, and follow-up questions across many devices and many review divisions, which is what calibrates our internal templates and our sense of where the bar actually is at any given moment. Second, it represents recurring engagements with the same manufacturers across multiple devices and product generations, meaning the work survives the only test that matters, which is whether the customer comes back the next time. We are happy to share anonymized examples of cybersecurity sections from cleared submissions during scoping calls, subject to the confidentiality terms of our prior engagements. The volume also matters at a practical level for capacity: we can usually start a premarket pen test within one to two weeks of contract signature without juggling other work, because the team is sized for steady throughput on this specific kind of engagement rather than scrambling to repurpose generalist consultants for a niche regulatory context.

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–24-hours, often the same business day if the language is standard. We also accept client-paper NDAs and have reviewed enough variants to negotiate quickly without a long legal back-and-forth. For engagements that involve PHI, for example pen testing of a connected device that processes patient data in a clinical setting, we sign a HIPAA-compliant BAA prior to any data transfer and route all PHI through encrypted, access-controlled environments segregated from our other engagements. We are equally comfortable operating under client-supplied data processing addenda for international engagements (GDPR-aligned DPAs, UK addenda, etc.). Source code and firmware are handled in isolated build/test environments with access limited to the named engineers on your engagement; on close-out, we destroy or return all artifacts per your data handling requirements and provide a written attestation of destruction. None of this is unusual for medical device work, but it is worth confirming early so legal review does not block the engineering schedule. Customers occasionally ask whether we can review legal language faster than 24–24-hours. Usually yes, for standard mutual NDAs we can turn around inside a single business day when needed. The legal step has never been the bottleneck on a Blue Goat engagement, and we work hard to make sure it stays that way.

Question 10

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

Accepted Answer

Section 524B of the Federal Food, Drug, and Cosmetic Act, added by the Consolidated Appropriations Act of 2023 (the omnibus 2023 act), gives the FDA explicit statutory authority to require cybersecurity information in premarket submissions for 'cyber devices.' 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. Submissions for cyber devices must include a Secure Product Development Framework (SPDF), a Software Bill of Materials (SBOM) in machine-readable form, evidence of vulnerability monitoring and patching, and design and architecture documentation that lets a reviewer assess the device's security posture. Section 524B is what gives the FDA the authority to refuse to accept a submission that does not include these artifacts, making cybersecurity a true gating item rather than a nice-to-have. The statute also gives the FDA the operational hook it had previously lacked: prior to Section 524B, cybersecurity was guidance-only and reviewers had to argue that a deficiency was material to safety and effectiveness. Now reviewers can reject submissions that do not include the required cybersecurity content outright, which has changed how seriously sponsors prepare for review.

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 System Considerations and Content of Premarket Submissions,' supersedes the September 2023 final guidance and represents the FDA's current thinking on what a cyber device cybersecurity submission must contain. The major changes from the 2023 version include: tighter expectations around SPDF artifacts (reviewers want to see evidence the framework is actually followed, not just documented); more rigor in threat modeling, with explicit expectations around STRIDE-style decomposition, attack trees for high-risk flows, and traceability into ISO 14971 risk controls; explicit endorsement of machine-readable SBOM formats (SPDX 2.3+ and CycloneDX 1.4+) with VEX statements for known CVEs; clearer expectations for security architecture views (global system view, multi-patient harm view, updateability/patchability view, and security use case views); and stronger language around postmarket commitments including coordinated vulnerability disclosure and a defined patch cadence. Submissions filed after February 3, 2026 are reviewed against this new bar. We re-baselined our internal templates within weeks of the guidance release, and have already supported submissions cleared under the new expectations. The most important practical implication for sponsors is that older internal templates need to be re-baselined: a cybersecurity section that cleared review in 2023 may not clear review in 2026 even if nothing about the device has changed, simply because the bar has moved. We routinely run a one-week pre-submission readiness check against the 2026 expectations, which catches the gaps that would otherwise come back as deficiencies. Catching them ahead of submission is dramatically faster than fixing them under the clock of an information request.

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. The FDA's expectation is not just that you have an SPDF, but that the SPDF produces objective evidence at each lifecycle stage: design inputs that include security requirements, threat models that are updated as the architecture evolves, secure-coding standards with enforcement mechanisms (SAST, code review), verification activities that include both automated scanning and manual penetration testing, release processes that include cryptographic signing and SBOM generation, and postmarket processes that include continuous SBOM/CVE monitoring, coordinated vulnerability disclosure, and a patch cadence. The SPDF is typically anchored in your existing ISO 13485 quality management system so that cybersecurity activities produce records under design controls (21 CFR 820.30 / ISO 13485 §7.3) and risk management (ISO 14971). For premarket submissions we deliver an SPDF summary describing the framework, plus the artifacts that demonstrate the framework was followed for the specific device under review. Reviewers care more about the artifacts than the framework document itself, they want evidence, not promises. A useful sanity check on your SPDF is whether you can hand a reviewer the document and the corresponding artifacts side by side and have the artifacts visibly support the framework's claims. If the SPDF claims threat modeling on every release but the threat model in the design history file is two years old, that gap is exactly what reviewers find. We help close those gaps and produce evidence trails that hold up.

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). We deliver every premarket cybersecurity package in formats that drop directly into those eSTAR sections, properly labeled PDF artifacts for the threat model and architecture views, machine-readable SBOM in SPDX 2.3 or CycloneDX 1.4+ JSON, a structured security risk assessment that traces into your ISO 14971 risk file, and a pen test report formatted to the FDA's expectations for evidence of manual exploit-driven testing. We can also provide a pre-submission readiness check where we map your existing artifacts directly to the eSTAR cybersecurity sections and identify gaps before you upload. That pre-check is included free for clients we are engaged with on the underlying work, it tends to save weeks of back-and-forth during the actual submission. The other practical implication is that file naming, section labeling, and document metadata all matter, eSTAR is automation, and reviewers see exactly what the template surfaces. Sloppy organization shows up immediately. Our deliverables ship with the conventions that drop into eSTAR cleanly, which is a small detail with an outsized effect on how a submission reads on the reviewer's screen.

Question 14

What SBOM format does the FDA accept?

Accepted Answer

The FDA accepts Software Bills of Materials (SBOMs) in machine-readable formats, specifically SPDX 2.3 or later (ISO/IEC 5962) and CycloneDX 1.4 or later. Both formats are explicitly endorsed in the 2026 final guidance and in ANSI/AAMI SW96. We typically deliver CycloneDX 1.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. Each SBOM we deliver includes the device's first-party application code, third-party libraries with version and license metadata, embedded operating system and bootloader components, and, for connected ecosystems, companion mobile app and cloud back-end SBOMs as separate documents tied together by a top-level assembly SBOM. We also deliver human-readable views (PDF and HTML) for the regulatory file, but the machine-readable SBOM is what satisfies the Section 524B statutory requirement. Critically, we deliver the SBOM with VEX statements for every known CVE affecting any listed component, so reviewers can immediately see which vulnerabilities are exploitable in your device's intended use context and which are not, saving substantial back-and-forth during review. For customers whose downstream consumers (hospitals, IDNs, government buyers) require additional formats, for example SPDX 3.0, SWID tags, or CSAF for vulnerability disclosures, we generate those alongside the FDA-targeted CycloneDX without re-running the underlying analysis. One SBOM pipeline, multiple presentation formats, all reconciled to the same source-of-truth component inventory.

Question 15

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. Second, binary analysis, Binwalk for filesystem extraction, Ghidra-assisted reverse engineering, and signature-based identification of statically linked libraries (zlib, OpenSSL, mbedTLS, lwIP, FreeRTOS, etc.), to capture components that the build system did not declare. Third, OS image analysis for embedded Linux devices, including kernel modules, device-tree blobs, and bootloader components (U-Boot, GRUB, vendor-specific secure-boot loaders). The combined output is a single CycloneDX SBOM that distinguishes declared vs discovered components and includes cryptographic hashes for tamper-evidence. For complex devices we also generate a dependency-of-dependencies (transitive) graph so reviewers can answer 'where does this CVE actually live?' without re-running the analysis themselves. The output is reviewable by humans and ingestible by tools. We deliver the CycloneDX JSON with cryptographic hashes, a human-readable PDF for the regulatory file, and a CSV for engineering teams that prefer to work in spreadsheets. We also sign the SBOM with our engagement key so any downstream consumer can verify it has not been altered after delivery, which is increasingly required by hospital procurement teams under recent FDA and federal guidance.

Question 16

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. A VEX statement, attached to the SBOM, declares for each known CVE one of four statuses: 'not affected' (the vulnerable code path is not present, not configured, or not reachable in the device's intended use), 'affected' (the device is vulnerable and the issue is being remediated), 'fixed' (a patch has been applied and validated), or 'under investigation' (analysis in progress with a target date). For each CVE we also document the technical justification, for example, that an OpenSSL vulnerability in TLS renegotiation does not apply because the device pins TLS 1.3 with renegotiation disabled, or that a zlib heap overflow is not reachable because the device's only consumer of compressed data is a signed firmware update with bounded inputs. This turns a continuous scan from an unbounded list of red flags into a small list of items that genuinely need engineering attention. We deliver VEX in CycloneDX format embedded in the SBOM and also as standalone CSAF documents when the customer's downstream consumers prefer that. Operationally we deliver this as a continuous service: the SBOM is loaded into a vulnerability intelligence platform, scanned daily, triaged weekly, and surfaced to your engineering team in your existing issue tracker. Quarterly we produce a summary report suitable for sharing with the FDA, your notified body, or your customers, whichever audience needs evidence that the postmarket program is real.

Question 17

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. We align the methodology to AAMI TIR57 (Principles for medical device security, risk management) and trace every identified threat into ISO 14971 risk controls so the threat model is not a separate artifact disconnected from your safety risk file. For complex SaMD or connected ecosystems we layer in PASTA (Process for Attack Simulation and Threat Analysis) to cover business-impact analysis, or LINDDUN where privacy threats are first-class concerns (for example, devices that handle special categories of personal data under GDPR). For AI/ML-enabled devices we add MITRE ATLAS-aligned analysis covering model-specific threats. The methodology is documented, repeatable, and produces a threat model artifact that survives reviewer scrutiny. The threat model is delivered as a versioned document under your design controls, with the underlying DFD and attack trees in editable form so your team can update them as the architecture evolves. We also provide a one-day handover workshop so internal engineers understand how the model was built and can extend it on subsequent releases without re-engaging us for every minor change.

Question 18

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. Companion apps: iOS and Android binary and runtime analysis (Frida, Objection, MobSF), insecure storage, certificate pinning bypass, IPC abuse, deep-link injection, and authentication weaknesses. Cloud and back-end: API authentication and authorization (OAuth, JWT, mTLS), tenant isolation, IDOR, injection classes, and infrastructure mis-configuration. Surrounding infrastructure: gateways, hubs, hospital-network integrations, EHR connectors. We map every test we run back to the threats in your threat model and to your intended-use environment, so the report tells you not just what we found, but which findings change the device's residual safety risk. Findings are tracked in a CVSS-scored issue tracker, retest is included, and the final report is formatted for the FDA submission. The other thing a real pen test covers is the assumption layer in your threat model. We deliberately probe the assumptions you have written down (for example, 'the user will not have physical access to the device' or 'the wireless link is only used in a hospital network') and report where reality differs. That is often where the most consequential findings live, and exactly the kind of analysis automated tooling cannot perform.

Question 19

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. The reason is that automated scanners are very good at finding known patterns (outdated library versions, default credentials, common web vulnerabilities) and very bad at finding the things that actually matter on medical devices: business-logic flaws, authorization bypasses specific to the device's roles, race conditions in firmware update flows, hardware-mediated attacks, and threats that require chaining several individually-low-severity findings into a clinically-significant exploit. We do use automated tooling, extensively, because it is the right tool for the bulk-coverage layer, but the deliverable is a manual penetration test report. Tools augment the testers; they do not replace them. Submissions that rely on scan output alone are routinely held up with deficiency letters asking for evidence of manual testing, which is a significantly more expensive way to discover the requirement than just doing it correctly the first time. A practical way to think about the difference: scanners answer 'are there any known patterns of vulnerability?' while pen testers answer 'can someone actually compromise this device in its intended use?' Reviewers care about the second question, because that is the one that maps to patient safety. Submissions structured to answer it explicitly clear review faster than submissions that try to substitute scanner output for the real analysis.

Question 20

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. That is exactly what reviewers want to see, a final report with no open Critical or High findings, or with explicit, well-justified risk acceptances for any remaining items. Retest is included because incentives matter: if retest were billable, there would be a quiet pressure to grade ambiguous findings as exploitable so they generate retest revenue, and to resist closing them. We would rather take that pressure off the relationship entirely. If you need additional retests beyond the included one, for example because a major architecture change between rounds materially expanded the attack surface, those are billed at a transparent fixed fee disclosed in the original SOW, with no surprises. The retest is also useful to your engineering team because it validates that fixes work in the assembled device, not just in a unit test. Several times a year we find that a fix closes the original vulnerability but introduces a new one, or fails to close it under a slightly different attack path. Catching that before submission is much cheaper than catching it after.

Question 21

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 2025 postmarket 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. Second, a coordinated vulnerability disclosure (CVD) policy published on your website with a security.txt file, a disclosure email, a defined acknowledgement and response timeline, and (for many manufacturers) a safe-harbor commitment for good-faith researchers. Third, a defined patch validation cadence, typically time-bound by severity (e.g., critical vulnerabilities patched and shipped within X days), with regression and security testing integrated into the release pipeline. Fourth, FDA reportable event templates and decision trees so when an event occurs, the timeline does not start with 'how do we file this?' Fifth, customer advisory templates so customers (hospitals, IDNs, distributors) get clear, consistent communications. We help build the program, train your internal team, and can also operate parts of it as a managed service for smaller manufacturers without a dedicated PSIRT. The program is documented under your QMS so audits, FDA inspections, and notified body assessments find a coherent trail of policy, evidence, and continuous improvement. We produce the artifacts in formats that integrate cleanly into your existing document control system rather than living in a separate vendor portal that your auditors cannot easily reach.

Question 22

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, 2025 postmarket guidance, ANSI/AAMI SW96, AAMI TIR57/97), benchmarked against the artifacts you currently have. We then build a remediation roadmap that prioritizes work by both regulatory exposure and clinical risk: typically generating an SBOM (often via binary analysis where source is unavailable for older modules), a security risk assessment, a threat model, architecture views, and the supporting test evidence. Where the original device design cannot reasonably be modified, for example, an implantable cleared a decade ago that cannot accept new firmware, we document compensating controls and residual risk justifications that align with ISO 14971 and have survived FDA review on similar devices. The roadmap is designed to produce a defensible cybersecurity package without forcing a redesign, and to give you a clear plan when reviewers ask 'what is your trajectory toward current expectations?' on the next supplement. The most common surprise during legacy modernization is that source code or build artifacts for older modules are no longer available, the original developers have left, the build server has been retired, or the third-party vendor is out of business. We have well-established workflows for that scenario (binary analysis, decapping, vendor outreach, controlled re-baselining) and have completed many engagements where the device shipped years before the team that originally built it dispersed.

Question 23

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. For EU MDR specifically, our threat models, security risk assessments, and architecture documentation map directly to Annex I GSPR 17.2 (IT security and minimum requirements) and the supporting expectations in MDCG 2019-16 'Guidance on Cybersecurity for Medical Devices.' We align lifecycle process documentation to IEC 81001-5-1 (health software lifecycle security) and IEC TR 60601-4-5 where applicable. For the EU Cyber Resilience Act (CRA), which applies to products with digital elements being placed on the EU market, we map deliverables to the essential cybersecurity requirements in Annex I and the conformity assessment expectations, recognizing that for most medical devices the MDR pathway will provide the relevant CE marking but the CRA's transparency, vulnerability handling, and update obligations may still apply to non-medical components or services. We also support EU Authorized Representative coordination on cybersecurity content so your EC REP has what they need for incident reporting under both MDR Article 87 and the CRA's vulnerability disclosure obligations. The interaction between MDR, CRA, the NIS2 Directive, and sector-specific regulations is genuinely intricate, and is being clarified by EU bodies on a continuing basis. We track the guidance updates and adjust deliverables accordingly so customers do not have to follow every working paper from MDCG, ENISA, and the European Commission to stay compliant. When a position is genuinely unsettled we flag the uncertainty in the deliverable rather than pretend the regulatory text is more definitive than it is.

Question 24

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. We address model-specific risks: data poisoning during training, model inversion and membership inference attacks against trained models, adversarial examples designed to flip a clinically-meaningful classification, prompt injection for LLM-based clinical features, jailbreaks that bypass safety guardrails, and supply-chain risks against pre-trained foundation models. We also address the more conventional risks specific to ML deployments: model artifact integrity (cryptographic signing of model files, verification at load time), inference API authentication and rate limiting, training-data confidentiality (PHI in training corpora), and observability for drift and degradation. Threat models are built using STRIDE plus MITRE ATLAS coverage, and PCCPs are written so the change-control envelope is cleanly demarcated and operationally enforceable. We also produce labeling content describing model provenance and update behavior in a form that satisfies both the FDA's transparency expectations and clinical end-user needs. For customers building genuinely novel AI-enabled devices, for example, generative AI clinical decision support or large multimodal models embedded in diagnostic workflows, we also support pre-submission strategy with the FDA, including Q-Sub preparation focused on the cybersecurity dimensions of the proposed device. Engaging early with the agency on novel architectures tends to dramatically reduce the number of deficiencies during formal review.

Question 25

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. That includes: penetration testing (manual, exploit-driven, against device hardware, firmware, companion apps, cloud back-ends, and surrounding infrastructure); SBOM generation and management (SPDX 2.3 or CycloneDX 1.4+ machine-readable, with VEX triage); threat modeling (STRIDE-per-element with attack trees, traced into ISO 14971 risk controls); security risk assessment (a structured analysis of cybersecurity-related risks to safety and effectiveness); SAST and SCA (static application security testing and software composition analysis with finding triage); secure design and architecture consulting (security architecture views including global system, multi-patient harm, updateability/patchability, and security use case views); secure coding standards rollout; FDA deficiency response (rapid remediation and resubmission of cybersecurity items in FDA information requests); and pre-submission readiness reviews (calibrating your full cybersecurity package against current reviewer expectations before you file). Engagements can be scoped as fixed-fee single deliverables or as full-package premarket programs that produce every cybersecurity artifact your eSTAR submission requires. The latter is what the majority of our customers choose because it eliminates the integration risk between artifacts produced by different vendors. Engagements are scoped from a Discovery Session against your specific device, target submission date, and existing artifacts. We do not pre-package a one-size-fits-all bundle, because device class, connectivity model, and regulatory pathway all shift the right scope. The SOW you receive is calibrated to what your submission actually requires, not to what is convenient for us to deliver.

Question 26

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. A real pen test produces the kind of evidence reviewers can rely on: a documented methodology, a defined scope tied to your threat model, manual exploitation against the device's actual attack surface, CVSS-scored findings with exploitability evidence, and a remediation/retest record. Operational: a real pen test finds vulnerabilities that scanners cannot, business-logic flaws specific to your device, authorization weaknesses across your roles and tenants, hardware-mediated attacks (debug ports, glitching, side channels), update-flow exploits, and chained vulnerabilities where several individually low-severity issues combine into a clinically-significant compromise. The cost of finding these in pen testing is small compared to the cost of finding them in postmarket, through a coordinated vulnerability disclosure, a security researcher's blog post, or worse, a real incident. For Class II and Class III devices the FDA's intended-use safety analysis often hinges on cybersecurity assumptions that only a pen test can validate. The economics also favor doing it well. A pen test scoped properly during the verification phase typically costs a small fraction of what it costs to remediate a postmarket cybersecurity incident, deal with an FDA Class I recall, or respond to a public coordinated vulnerability disclosure. Treating cybersecurity testing as an investment rather than a checkbox is one of the most reliable predictors of which manufacturers stay out of avoidable trouble in the field.

Question 27

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. Maintenance means the SBOM regenerates automatically on every build so it stays synchronized with shipped firmware versions, with cryptographic hashes that allow tamper-evidence. Distribution means delivering the SBOM in the formats your downstream consumers need, to the FDA in CycloneDX or SPDX as part of the submission, to hospital customers in their preferred format, and to your internal vulnerability monitoring platform. Action means continuously scanning the SBOM against vulnerability intelligence (NVD, GHSA, vendor PSIRTs), triaging hits with VEX statements, and feeding genuinely-applicable vulnerabilities into your engineering backlog with appropriate severity. Done well, SBOM management aligns with the FDA's 2026 premarket guidance, the 2025 postmarket guidance, ANSI/AAMI SW96 supply chain expectations, and the EU CRA's vulnerability-handling obligations. Done poorly, it generates an unbounded list of CVEs that nobody has time to triage and that ultimately undermines the postmarket program. For most manufacturers the bottleneck is not generating the SBOM, it is operating the program around it: triage, VEX authoring, integration with the engineering backlog, and audit-ready reporting. That is exactly the part we run as a managed service for customers without a dedicated PSIRT, so the SBOM stops being a one-time submission artifact and becomes the living document the regulations actually expect.

Question 28

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. Step one is a rapid analysis of the deficiency letter, typically within 24-hours of receipt: we map every reviewer comment to a specific cybersecurity artifact, identify whether the issue is a documentation gap, a real technical gap, or a misinterpretation of evidence already submitted, and produce a response strategy with a defensible position on each item. Step two is targeted remediation, generating new artifacts, re-running tests, updating the SBOM and VEX, expanding the threat model, or producing the supporting architecture views the reviewer asked for. Step three is updated documentation, written in language that directly addresses each reviewer comment with cross-references to the new evidence. Step four is the resubmission package, formatted to drop straight back into the eSTAR. Most cybersecurity deficiencies are closed on first resubmission when handled this way. The work is fixed-fee, scoped from the deficiency letter, and includes follow-up reviewer questions if any arise from the resubmission, so you have one number, one team, and a clear path back to clearance. We also keep a running anonymized library of deficiency patterns we have seen across submissions, so when a new letter arrives we can usually identify the underlying reviewer concern quickly and respond to the actual issue rather than the surface wording.

Question 29

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). The exact timeline depends on the scope of the deficiencies, a small set of documentation clarifications can close in under a week, while a request for a full new threat model plus additional pen testing on a complex device may run the upper end of the range. For genuinely urgent situations, for example, a launch window threatened by an unexpected hold, we offer rush engagements with a target turnaround under two weeks, including weekend and after-hours work, scoped at a transparent rush rate disclosed in the SOW. The other thing that affects timeline is internal coordination on your side: if your engineering team is responsive on technical questions about the device, we move fast; if access to the device, source code, or subject matter experts is delayed, the schedule moves with it. We make that dependency explicit at engagement start and provide a daily status during deficiency response so there are never surprises about where time is being spent. For especially compressed timelines we can also stand up a daily standup with your regulatory affairs lead and engineering points of contact so the response is built collaboratively rather than handed over at the end.

Question 30

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. Coordinated vulnerability disclosure (CVD) program design and operation, published policy, security.txt, intake email, researcher acknowledgment workflow, and (for managed-service customers) handling of incoming reports on your behalf. Patch management and validation, defining your patch cadence by severity, integrating security regression testing into release pipelines, and producing the validation evidence the FDA expects when a software update is filed. Incident response, playbooks, tabletop exercises, on-call retainer for active incidents, and FDA reportable event support including timelines, communications, and root-cause documentation. Legacy device security, gap assessments, compensating controls, and remediation roadmaps for devices that pre-date current expectations. Customer advisory communications, templated, calibrated for hospital and IDN consumers. Annual cybersecurity reviews mapped to the 2025 postmarket guidance and your QMS. The portfolio is built so a single retained partner covers everything FDA, EU MDR, Health Canada, TGA, and PMDA expect from a connected device manufacturer in the field, without you needing to staff a full internal PSIRT. Postmarket engagements are typically structured as annual retainers with monthly working sessions and quarterly reporting suitable for executive leadership and external auditors. The reporting cadence is designed to give your leadership a clear, defensible view of cybersecurity posture across the deployed fleet without forcing them to reconstruct it from raw scan data.

Question 31

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). Threat actors continually develop new techniques, including those targeting healthcare specifically. Hospital networks change. Companion apps update. Cloud back-ends migrate. Your device, fixed at the moment of clearance, sits in the middle of all of that. The FDA's 2025 postmarket guidance, EU MDR Article 87 incident reporting, the EU Cyber Resilience Act's vulnerability handling obligations, and IMDRF guidance all create explicit obligations to monitor, triage, patch, and disclose. Beyond regulation, the operational reality is simpler: a real cybersecurity incident on a deployed medical device can cause clinical harm, trigger Class I recalls, and consume engineering resources for many months. A well-run postmarket program, continuous SBOM monitoring, a real CVD policy, a defined patch cadence, and rehearsed incident response, turns a potential corporate-existential event into a managed engineering process. The cost of building it is small relative to the cost of not having it when you need it. There is also a competitive dimension: hospital procurement teams increasingly require evidence of an active postmarket cybersecurity program before purchasing connected devices, and many issue questionnaires modeled on the MDS2 form. Manufacturers who can answer those questions cleanly win deals; manufacturers who cannot, lose them or are forced into long, expensive procurement-cycle remediation.

Question 32

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. We align to ISO 13485 (quality management systems for medical devices), ISO 14971 (risk management for medical devices, the foundation that cybersecurity risk plugs into), ANSI/AAMI SW96 (medical device security risk management), AAMI TIR57 and TIR97 (security risk management principles and postmarket security), IEC 81001-5-1 (health software lifecycle security), IEC TR 60601-4-5 (medical electrical equipment security capabilities), IEC 62304 (medical device software lifecycle), EU MDR Annex I GSPR 17.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. The same threat model, SBOM, VEX, security risk assessment, architecture views, and pen test report, properly structured, satisfy the cybersecurity content requirements across all these regimes, what changes is the wrapper documentation and the regulatory-affairs framing for each filing. We coordinate with your EU Authorized Representative, UK Responsible Person, and other in-country agents so cybersecurity artifacts plug into each regional submission cleanly. For multi-region launches we also produce a regulatory crosswalk document, a single matrix mapping each cybersecurity artifact to each region's specific clause or guidance section, so your regulatory affairs team can demonstrate coverage to internal stakeholders, notified bodies, and auditors without rebuilding the analysis for every jurisdiction.

Question 33

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. You will leave the call with a clear picture of what the FDA's 2026 final guidance expects for your specific device class, where your existing artifacts stand against that bar, and a realistic timeline and budget range for closing the gaps. If we are a good fit, the next steps are an NDA (typically signed within 24–24-hours), a scoping conversation that produces a fixed-fee SOW, and engagement kickoff within 1–2 weeks of contract signature. If we are not the right fit, for example because your timeline requires onsite work in a region we do not cover, or because your device is outside our specialization, we will say so and where possible refer you to someone better suited. Honest scoping calls produce better engagements than aspirational ones. Most prospects book a Discovery Session within a week of first contact and have a scoped, fixed-fee SOW within ten business days of that call. If you have a hard deadline driving the engagement, mention it on the booking form so we can prioritize accordingly.

Question 34

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. Pricing is calibrated by deliverable: a premarket pen test on a single connected device with companion app and cloud back-end falls in a defined range; a complete premarket cybersecurity package (threat model, SBOM, security risk assessment, architecture views, pen test, all formatted for eSTAR) falls in a different defined range; a postmarket retained program is priced annually with deliverable-level commitments. Discovery calls produce indicative ranges immediately and a precise SOW within a week of receiving enough information to scope accurately. Pricing includes one round of remediation retest on pen tests, follow-up reviewer questions on deficiency response engagements, and reasonable revision cycles on documentation deliverables. We publish a typical-engagement cost calculator on the site and discuss exact numbers candidly during scoping, surprises are bad for everyone, especially us. We also publish indicative ranges for our most common engagement types on the site, so you can build internal budget estimates before a formal scoping call. The numbers shift modestly with device complexity, but they are accurate enough to use for board-level planning without surprise during contract.

Question 35

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). A complete premarket cybersecurity documentation package, threat model, security risk assessment, SBOM, architecture views, formatted for eSTAR, runs 4–6 weeks depending on the maturity of the underlying design documentation. A combined premarket program that produces every cybersecurity artifact your submission requires runs 6–10 weeks and is the most efficient way to engage if you are filing a 510(k), De Novo, or PMA in the next quarter. FDA deficiency response packages run 2–4 weeks (with rush options under 2 weeks). Postmarket programs are continuous engagements with deliverable cadences defined annually. Timelines depend most on three things: scope (clear and bounded vs evolving), responsiveness (engineering team availability for technical questions), and access (device, source code, build artifacts ready at kickoff vs trickling in). We confirm timeline at SOW and provide weekly status throughout. For multi-quarter programs, full premarket portfolios across several devices, or annual postmarket retainers, we run a quarterly planning cadence so the work integrates with your overall regulatory calendar rather than competing with it. Predictable delivery is one of the things customers cite most often when they renew, and we treat schedule reliability as a deliverable in its own right.

Question 36

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. For genuinely urgent engagements, most often FDA deficiency response with a tight resubmission window, but sometimes pre-launch pen tests where a target submission date is non-negotiable, we can compress kickoff to days rather than weeks, including weekend mobilization, scoped at a transparent rush rate disclosed in the SOW. The factors that move the schedule are usually on the customer side rather than ours: legal review of the SOW, internal procurement, and getting the device or build artifacts physically and digitally available to our team. We flag those dependencies explicitly during scoping so the timeline is realistic from day one rather than slipping after kickoff. If you have an immediate need, the Discovery Session is the fastest way to get a real answer about start date. For customers who anticipate an upcoming submission but have not yet finalized the device, we also offer a soft hold on calendar capacity, no commitment, no fee, so when you are ready to engage the team is available without a queueing delay. That option is most useful for sponsors with a known submission window months ahead but uncertain final scope today.

Question 37

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. The reason is operational, not philosophical: medical device cybersecurity is a small, technical specialty where the quality of the deliverable depends entirely on the specific person doing the work, and our reputation cannot survive a generic pen test report sliding past quality control because the actual author was unaccountable. Lead engineers on engagements are named in the SOW and disclosed in the final report. Our long-term partners, used for capacity smoothing on specialized hardware engagements (chip-off firmware extraction, RF lab work, specific FPGA reverse engineering), are individuals we have worked with for years, on our paper, under our quality system, and under the same NDA and BAA terms as our employees. If you need to verify the team that will work your engagement before signing, we share lead engineer profiles on request during scoping. The W-2 model also has a quality and continuity benefit: the engineer who runs your initial pen test is typically still available for the retest, the deficiency response, and the next product in your portfolio. That continuity compounds over time and is one of the main reasons customers return for subsequent engagements rather than restarting the procurement process for every new device.

Question 38

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. Specifically: source code is stored in a per-engagement encrypted repository with role-based access control; analysis is performed on per-engagement virtual workstations that cannot exfiltrate data to general-purpose internet endpoints; physical devices are stored in access-logged secure rooms when not under active test; and any PHI handled during testing flows through a HIPAA-compliant pipeline under an executed BAA. Internal access is governed by least-privilege, engineers on one engagement do not have visibility into another engagement's repository, devices, or artifacts. Multi-factor authentication is enforced on every system that touches client data. At engagement close, all source code, firmware, and analysis artifacts are destroyed (or returned, per your data-handling preference) within an agreed period, typically 30 days unless you require shorter, and we provide a written attestation of destruction. We are happy to complete supplier security questionnaires, share our information security policies, and accept additional contractual protections (specific encryption standards, data residency commitments, audit rights) when your customers' procurement processes require them. We also undergo periodic third-party security assessments of our own infrastructure and are happy to share the executive summary on request. Asking your cybersecurity vendor about their own security posture is a healthy practice that we encourage, the firms that take their own security seriously are the ones most likely to take yours seriously.

Question 39

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. Practically that means: completing your supplier qualification questionnaire and onboarding process; signing a quality agreement that defines deliverable acceptance criteria, change control, and complaint handling; producing deliverables under your document control conventions (template, numbering, review/approval routing); supporting your design controls and design history file (DHF) requirements by producing artifacts in forms that integrate cleanly into the DHF; supporting your risk management file by tracing cybersecurity threats and controls into your ISO 14971 file with the right identifiers; and providing objective evidence (qualifications, training records, methodology documentation, work product) for internal audits and notified body audits. We have been audited by FDA, notified bodies (BSI, TÜV SÜD, BSI BV), and customer quality teams as an outsourced cybersecurity supplier and are familiar with the depth and form of evidence those audits expect. If your QMS includes specific requirements we have not encountered before, for example novel data-handling controls or unusual document templates, we will accommodate them rather than push back. Operating cleanly under client QMS arrangements is part of the work. For first-time engagements with a customer's QMS we typically allow an extra week at engagement start for QMS onboarding, completing the supplier qualification, signing the quality agreement, and aligning on document control conventions. Building that buffer in once means the rest of the engagement runs cleanly under your QMS without rework, which is usually faster overall than trying to retrofit compliance after the deliverables are drafted.

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

Working with Us

Get FDA cleared without the cybersecurity headaches.