Conducting a Medical Device Security Audit

Reviewed July 24, 2026

An audit should show whether security controls protect patient safety, data, and clinical operations, not just whether documents exist. We look for evidence that connects each security claim to the device being shipped.

In the FDA letters we reviewed for our September 2026 MTEC webinar, one submission drew nine separate findings for controls described only at a high level. That is a useful audit check: can we trace each control to a specific requirement and test result, or are we accepting a statement of intent?

Why this matters

A medical device security audit should tell us whether an attacker can expose patient data, change device behavior, or interrupt care. We need evidence that controls work, not just a policy saying they exist. Regular audits help identify weaknesses before exploitation and reduce exposure to patient harm, regulatory non-compliance, legal liability, and reputational damage.

On a Class II wearable we tested, loss of the RF link caused the device to buffer telemetry silently. A clinician-visible alert appeared only after 30 minutes of continuous loss. That finding connected a wireless availability problem to a clinical workflow: the audit needed to examine not only whether communication could fail, but whether clinicians would know. The recommended fixes included a configurable connectivity-loss alert threshold and labeling that explained the failure mode.

The FDA’s February 3, 2026 final guidance addresses cybersecurity throughout the total product lifecycle. We audit against those expectations and applicable standards, including IEC 81001-5-1, ISO 27001, and AAMI TIR97. This is the part teams skip: finding a weakness is not closing it. Manufacturers need an assigned remediation, updated risk documentation, and retest evidence showing whether the control now protects device integrity, patient information, and continuity of care.

The Critical Need for Cybersecurity in Medical Devices

From wearable insulin pumps to MRI systems, connected devices expose interfaces that attackers can use to reach patient data or disrupt care. We audit those interfaces to check whether security controls hold up under attack, not just whether the documentation names them.

On a Class II wearable we tested, an attacker within BLE range could pair without user interaction and change alerting thresholds through a writable GATT characteristic. That is why an audit must connect unauthorized access to its potential effect on patient safety.

Running a device security audit?

Blue Goat Cyber is a medical-device-only cybersecurity firm. Our team runs the threat modeling, penetration testing, and FDA-facing documentation MedTech submissions live or die on. → Medical device penetration testing

Medical Device Cybersecurity Audit Steps

Step 1: Defining the Scope of Your Audit

We start by defining the system, not just the device enclosure. An audit should cover design and development through post-market surveillance, including the hardware, software, connected services, and people who maintain the product. Record the versions under review, deployment environments, system owners, and any exclusions before testing begins.

Use software composition analysis to examine software dependencies, but do not mistake that inventory for the whole scope. Companion apps, cloud services, maintenance tools, and manufacturing systems can affect device security even when they are delivered or operated separately.

We build the scope around these areas:

• Early Inclusion of Devices: Include devices while architecture and implementation decisions can still change. Identify which controls can be reviewed during design and which require working hardware or release software. An early audit should produce engineering decisions, not just a list of tests deferred until the submission deadline.

• Software Composition Analysis: An examination of software components should identify open-source and third-party packages, their versions, known vulnerabilities, and applicable licensing obligations. Compare the inventory with the software that actually ships. Record dependencies that the analysis cannot identify rather than treating an incomplete result as a clean bill of health.

• Hardware Security Evaluation: Cover physical access paths and hardware features that affect remotely reachable controls. Depending on the threat model, this can include side-channel testing, secure boot processes, debug interfaces, and communication ports. State which production protections are enabled on the test units so results reflect the shipped configuration.

• Network Capabilities and Interoperability Security: List each interface, protocol, connected system, and trust boundary. Assess encryption in transit, authentication, authorization, and the permissions granted to interoperating systems. Do not assume that a hospital network or an internal connection supplies the controls missing from the device.

• Data Storage and Transmission Features: Identify where patient data, credentials, configuration, and logs reside and where they travel. Include encryption at rest, key handling, access restrictions, and exposure during transmission. Follow data through intermediate systems rather than stopping at the device's network connection.

• Regulatory Compliance and Standards Adherence: Identify applicable requirements from the FDA, along with relevant standards such as ISO/IEC 27001 for information security management and ISO 14971 for medical device risk management. Record how each applies. A standards list without an applicability assessment does not define an audit.

• Vulnerability Management and Incident Response: Include vulnerability monitoring, update delivery, patch decisions, and incident communications. Identify who receives reports, who assesses patient impact, and who authorizes a response. Review how those responsibilities continue after release and when a supplier stops supporting a component.

• User Access Controls: Cover authentication, role-based permissions, and audit trails for users and administrators. Assess multi-factor authentication where appropriate to the workflow. Include account provisioning, credential recovery, and removal of access, not just the login screen.

• Physical Security Measures: Consider unattended devices and use in public or semi-public areas. Review tamper-evident features, access to ports, and secure storage when the device is not in use. Document the physical protections expected from the deployment environment.

• End-to-End Security Testing: Include penetration testing and dynamic analysis across the components that support device operation. Define which interfaces and attack paths will be exercised, along with any safety constraints or exclusions that limit the conclusions.

• Review of Post-Market Surveillance Data: Examine post-market surveillance records for security signals, recurring failures, and unresolved reports. Confirm that the manufacturer can assess and address vulnerabilities discovered after deployment, including those reported through support rather than a formal security channel.

On a Class II wearable we tested, BLE connected the device to a companion app, while proprietary sub-GHz RF connected it to a home base station. The wearable had no direct cellular connection, but data left through the base station's LTE modem. Scoping only the wearable would have missed part of the system carrying its data.

The output of this step should be an agreed asset and interface inventory, lifecycle coverage, and a justified exclusions list. Those records establish what the audit can actually conclude about patient information, device integrity, and availability.

Step 2: Assembling a Specialized Team

We assign responsibilities before collecting evidence. A medical device security audit needs people who understand attack paths, implementation, clinical workflows, and regulatory commitments. One person may cover several roles, but no responsibility should disappear because the project is small.

The manufacturer also needs decision-makers who can approve design changes and fund remediation. Security testers can demonstrate a weakness and recommend controls; they cannot accept product risk on the manufacturer's behalf.

• Cybersecurity Experts: Security practitioners review the threat model, define attack paths, assess vulnerabilities, and test whether controls work under adversarial conditions. They should understand medical device constraints and distinguish a technical security impact from potential patient harm. Ask them to explain testing limits as clearly as findings.

• Engineers: Software and hardware engineers explain how the device works and how its controls are implemented. Software engineers address encryption, protocol behavior, and secure coding. Hardware engineers address tampering, physical interfaces, and hardware-backed protections. Both groups need access to the findings early enough to assess feasible changes.

• Designers: Designers examine how security controls affect device operation. Authentication, session handling, recovery, and update prompts must fit the intended workflow. Their role is not to remove controls whenever users find them inconvenient, but to help build controls that people can use correctly without obstructing care.

• Software Developers: Developers supply the implementation evidence behind the security claims. They connect requirements to code, dependency choices, configurations, and release records. We also involve them in reviewing security within the software development lifecycle (SDLC), including secure coding, vulnerability fixes, component updates, and the way changes reach released products.

• Regulatory and Compliance Specialists: These specialists identify applicable requirements and check that the audit evidence supports the submission and post-market obligations. They should flag unsupported statements, inconsistent terminology, and missing records. They also coordinate responses when a technical change affects labeling, risk documentation, or an existing regulatory commitment.

• User Experience (UX) Researchers: UX researchers examine actual user behavior, including workarounds and misunderstandings that may weaken security. They help assess whether users can recognize warnings, complete authentication, recover access, and apply updates. Their observations give the audit a firmer basis than assumptions about how clinicians or patients will behave.

Keep security testing sufficiently independent from the people who designed the controls. Developers should explain the implementation and help reproduce findings, but a developer's confidence in a feature is not independent evidence that it resists attack.

We also establish a working agreement: who supplies test units and credentials, who answers architecture questions, who owns each finding, and who reviews patient-safety implications. Schedule technical review meetings around evidence and decisions, not status slides.

The result should be a named responsibility list and a clear escalation path. When a finding crosses firmware, mobile software, and regulatory documentation, the audit should not stall while those groups decide who owns it.

Step 3: Conducting a Risk Assessment

We review risk across the device, its supporting systems, its deployment environment, and the data it handles. Start with the current architecture and threat model. Then identify what an attacker can reach, what access the attack requires, which controls intervene, and what happens if those controls fail.

Define the assessment method and acceptance criteria before assigning ratings. A label such as “Medium” is not useful unless the reader can reconstruct the reasoning. Keep the effect on confidentiality, integrity, or availability distinct from the resulting patient harm, while documenting the connection between them.

• Software Vulnerability Assessment: Examine the operating system, applications, firmware, and third-party or open-source components. Review findings from secure coding practices, static analysis, and dynamic testing alongside known component vulnerabilities. Assess whether vulnerable functionality is reachable in the actual configuration. Record patch availability, update constraints, and the evidence supporting any claim that a vulnerability is not exploitable.

• Physical Security Analysis: Evaluate how physical access could expose protected health information (PHI), alter device behavior, or bypass another control. Review ports, debug access, enclosure protections, and tamper-evident features. The assessment should account for use in hospitals, clinics, and patients' homes rather than assuming that every device stays in a controlled room.

• Data Privacy and Integrity Threats: Follow information through collection, storage, transmission, retention, and disposal. Consider applicable protections such as HIPAA in the United States. Review encryption, permissions, and secure deletion, but also assess unauthorized modification. Accurate, available clinical information matters alongside confidentiality.

• Network and Connectivity Risks: Map connections to electronic health record (EHR) systems, other devices, and cloud services. Review protocol security, segmentation, and monitoring for suspicious activity. Segmentation can reduce exposure, but it does not establish the identity or permissions of the system communicating with the device.

• User Authentication and Access Control: Assess passwords, biometrics, smart cards, or other authentication mechanisms against the actual access they protect. Review privileges after authentication, including administrative and service roles. Account for credential compromise, recovery procedures, and whether a user can perform an action outside their assigned role.

• Regulatory Compliance and Standards Adherence: Check that the risk process addresses applicable regional regulations and relevant standards, including ISO/IEC 27001 and ISO 14971 for risk management in medical devices. Use consistent risk identifiers across security and safety records so reviewers can follow the same issue without guessing which entries correspond.

• Incident Response and Recovery Planning: Assess how an incident would be detected, communicated, contained, and resolved. Review recovery of device functionality and data integrity, not just restoration of an IT service. Test the assumptions behind backup and recovery procedures and identify who decides when a device can return to use.

This is the part teams skip: revisit the rating after the control is specified and tested. A planned mitigation is not a demonstrated reduction in risk. Record the pre-control assessment, the control requirement, its supporting evidence, and the residual risk decision.

The assessment should end with an actionable risk register. Each entry needs an owner, an attack path, affected assets, potential harm, and a disposition. Uncertainty belongs in that record too; missing evidence should not quietly become a low rating.

Step 4: Reviewing Design and Development Protocols

We look for evidence that security affected design decisions, not merely that a security procedure exists. Review the development process against the product's actual history: when threats were assessed, when requirements were written, how controls were selected, and what happened when testing found a problem.

A useful audit follows selected controls from design through implementation and test results. If those records disagree, resolve the discrepancy before treating the control as complete.

• Security-by-Design Principles: Check whether each development phase includes security tasks, owners, and decision points. Review when threat modeling sessions occurred and whether their results changed architecture or requirements. A threat model produced after design freeze can still find problems, but it cannot show that security shaped the earlier decisions.

• Review of Development Protocols: Examine secure coding rules, code review practices, change controls, and developer training. Ask for records showing how those procedures are used. Confirm that the guidance addresses the languages, platforms, and interfaces in the product, rather than relying on generic training that developers cannot apply to their work.

• Security of Third-party Components: Compare the Software Bill of Materials (SBOM) with the release build and its dependencies. Review component names, versions, known vulnerabilities, support status, and update ownership. Check how the inventory changes when a library is replaced or updated, and how newly disclosed vulnerabilities reach the product's risk process.

• Vulnerability Management and Patching: Review monitoring for proprietary and third-party vulnerabilities, triage responsibilities, and patch release procedures. Examine how updates reach fielded devices, including over-the-air (OTA) delivery where used. The audit should assess update authenticity and integrity, installation failure handling, and the operational effects of applying a patch.

• Continuous Security Testing: Look for static code analysis, dynamic testing, and penetration testing at suitable points in development. Check how findings are reviewed and how significant changes trigger further testing. Test environments should reflect deployment conditions closely enough to support the conclusions being drawn.

• Regulatory Compliance and Standards: Map the development process to relevant requirements and standards, including ISO/IEC 27001, IEC 62304, and applicable FDA guidance. Keep the scope of each standard clear. Evidence of a software lifecycle process does not, by itself, show that the device's security controls resist attack.

For every sampled control, ask for specification-level detail. “Authentication is required” does not tell a tester which roles exist, how credentials are managed, or what happens after repeated failures. “The connection is encrypted” leaves the protocol, configuration, and certificate checks unanswered.

We also check whether release gates can stop a build with unresolved security concerns. A process that records findings but cannot affect release decisions is incomplete. The audit should show how exceptions are reviewed, how residual risk is accepted, and how deferred work stays visible.

The output is a development-process gap list tied to evidence and owners. It should separate missing procedures from failures to follow existing procedures, because those problems require different corrective actions.

Step 5: Analyzing Physical and Network Security

Device security depends partly on the environment that builds, configures, and supports the product. We review manufacturing facilities and IT infrastructure where a compromise could affect device software, production configuration, sensitive information, or service access.

Keep this work connected to the product. A general corporate IT assessment can be useful, but it does not replace analysis of the systems that can change what ships or how a fielded device operates.

• Physical Security of Manufacturing Facilities: Review controlled entry points, visitor access, surveillance, and protection of sensitive work areas. Assess whether access restrictions match the systems and information being protected. Biometric verification may be appropriate in some areas, but the audit should evaluate the complete access process, including exceptions and removal of access.

• Cybersecurity of Manufacturing Systems: Examine automation and quality-control systems for relevant cyber threats. Review firewalls, antivirus protections, intrusion detection, patching, and administrative access where applicable. Document operational constraints that prevent routine updates, along with the compensating controls and the person responsible for reviewing those exceptions.

• Secure Data Transmission: Review data exchanged within the manufacturing environment and with external systems. Protect proprietary and personal information in transit, and assess remote-access channels such as VPNs. Encryption should be paired with access restrictions and endpoint authentication; a protected connection can still carry unauthorized actions.

• Data Storage and Access Control: Identify where production records, sensitive data, and device-related information are stored. Review encryption at rest, segmentation, and access permissions. Check whether permissions are reviewed after role changes and whether administrators can access more information or functions than their work requires.

• Supplier and Third-party Vendor Security: Assess suppliers that handle sensitive information or connect to manufacturing systems. Review contractual security requirements and evidence that those requirements are followed. Periodic supplier audits should examine access, data handling, incident notification, and changes that could affect the device or its supporting environment.

• Employee Training and Awareness: Confirm that staff can recognize phishing attempts, secure workstations, handle sensitive information, and report suspicious activity. Training should reflect the tasks employees perform. Production and service personnel need to understand which actions could alter device configuration or bypass an expected protection.

• Incident Response and Recovery Plans: Review a response plan specific to the manufacturing environment. It should address containment, eradication, recovery, and assessment of affected product. Run drills that test communication and decision-making, including how staff determine whether a production system is safe to use again.

• Compliance with Regulations and Standards: Map the controls to applicable manufacturing requirements and relevant standards such as ISO/IEC 27001. Record the evidence behind each conclusion. A certification or policy can support the review, but it does not settle whether a particular production access path is adequately controlled.

We pay particular attention to boundaries between corporate IT, production, suppliers, and remote service access. Record which systems can cross those boundaries and what authorizes them. Treat undocumented connections as scope questions that need resolution, not as harmless background infrastructure.

The resulting findings should explain the product consequence. State whether the weakness could affect confidentiality, production integrity, device availability, or the ability to deliver trusted updates. That connection helps the manufacturer prioritize work without turning the device audit into an unrelated inventory of corporate IT issues.

Step 6: Conducting Penetration Testing

See also: 21 CFR Part 820 and Medical Device Cybersecurity, How SPDF Maps to IEC 81001-5-1 Activities, and IEC 81001-5-1 vs IEC 62304 for Medical Devices.

We use penetration testing to determine whether an attacker can defeat controls and what the resulting access allows. Scanning helps identify known vulnerabilities. It does not establish the full attack path or demonstrate its impact on device behavior.

Testing belongs in a controlled environment with agreed rules of engagement. Define safety limits, recovery procedures, permitted techniques, and the handling of patient information before active testing begins.

• Penetration Testing Framework: Set objectives, scope, methods, tools, and test conditions against the threat model. Include relevant wired, wireless, application, and update interfaces. Define when testing should repeat, including after significant changes to the device or its operating environment. Document exclusions and explain how they limit coverage.

• Engaging Expertise: Use testers who understand medical device behavior, embedded systems, and patient-safety implications. Maintain independence from the design team while giving testers enough architecture and implementation information to work effectively. An external perspective is useful only if the assessment reaches the interfaces and workflows that matter.

• Testing for Common Cyber Threats: Select scenarios based on credible attack paths. Malware, ransomware, data exfiltration, and phishing may be relevant to supporting systems and user workflows, but they should not become a generic checklist for every device. Where antivirus or anti-malware controls are claimed, test those claims within the agreed scope.

• Exploiting Identified Vulnerabilities: Attempt controlled exploitation when it is safe and authorized. Establish required access, attacker privileges, user interaction, and the effect on functionality or data integrity. If an exploit cannot be attempted safely, document the limitation and distinguish demonstrated impact from an impact inferred through analysis.

• Reporting: Record reproduction steps, affected versions, test conditions, evidence, and the consequences of each finding. Include prioritized remediation recommendations and trace findings to the threat model and risk file. A useful report lets engineers reproduce the issue and lets risk owners understand why it matters.

• Remediation and Re-testing: After changes are implemented, repeat the relevant tests against the corrected build. Confirm that the original attack fails for the intended reason and examine related paths where appropriate. Keep the original finding, the change, and the retest result connected in the record.

• Incident Response Planning: Use demonstrated attack behavior to refine detection and response procedures. Identify which logs, alerts, or user-visible symptoms would exist during an actual incident. If the test leaves no observable evidence, document that limitation rather than assuming operations staff would detect the same attack.

On a Class II wearable we tested, the OTA bootloader checked a CRC but did not verify a cryptographic signature. We modified one byte in a captured firmware image; the device installed it and rebooted into the modified firmware. That result demonstrated why an integrity claim based only on a CRC was insufficient. The recommended controls included signature verification before commit and an anti-rollback version counter.

A finding is not closed because a developer marks the fix complete. We need evidence from the corrected implementation. Security testing supplies that evidence; it does not replace the manufacturer's broader verification and validation responsibilities.

Step 7: Adhering to Regulatory Compliance

We map the audit to applicable requirements and the FDA’s guidelines for cybersecurity, including the February 3, 2026 final guidance. The audit should identify what applies, what evidence is expected, and where the current product or process falls short.

Keep regulatory requirements, guidance recommendations, and voluntary standards distinct. They serve different purposes. Treating them as interchangeable makes it harder to justify the scope and explain a gap.

• Understanding FDA Cybersecurity Guidelines: Review the FDA's expectations across design, development, submission, and post-market management. Identify the guidance sections relevant to the device and connect each to an artifact or activity. Avoid a compliance checklist that records “addressed” without naming the evidence and its location.

• Pre-Market Considerations: Assess whether cybersecurity risk management shaped the design, including encryption, secure connectivity, authentication, and supporting processes. Review the plan for identifying and mitigating risks. Frameworks such as NIST's cybersecurity framework and ISO/IEC 27001 can support the program, but device-specific implementation evidence is still needed.

• Post-Market Management: Review monitoring, vulnerability assessment, patching, and update delivery for fielded devices. Examine the coordinated vulnerability disclosure policy and participation in cybersecurity information-sharing forums or networks. Confirm who receives external reports and how those reports reach engineering, regulatory staff, and the patient-safety assessment process.

• Software Bill of Materials (SBOM): Maintain an SBOM that identifies the device's software components, including proprietary and third-party elements. For devices subject to section 524B, the SBOM is a statutory requirement, not simply a recommendation. Review how component information supports vulnerability management and reaches users who need it to manage exposure.

• Compliance Documentation: Collect risk assessments, control specifications, security test results, remediation records, and residual risk decisions. Include staff training records and monitoring and incident-response procedures where relevant. Check that the documents describe the same product version and use consistent identifiers, terminology, and conclusions.

• FDA Submission: Review the cybersecurity documentation required for the applicable pre-market submission. Explain the device's security features, risk management process, and testing evidence. Make sure a reviewer can trace a security claim to its requirement and result without reconstructing the connection from unrelated documents.

• Commitment to Patient Safety: Connect regulatory evidence to the effect on patients and clinical operation. Document what happens when a control fails or a service becomes unavailable. User-facing instructions should explain secure configuration, updates, recovery, and any operational responsibilities the risk assessment assigns to users.

We also review labeling as an actual deliverable. A plan to write instructions does not show that the customer will receive them. Check the content, the delivery method, and consistency with the tested configuration.

The audit should finish with a gap report against the applicable requirements, not a blanket statement that the device is compliant. Identify missing evidence, unresolved technical weaknesses, and process gaps separately. Closing those items supports a defensible submission, but an audit does not guarantee clearance or eliminate the possibility of questions from the FDA.

Step 8: Documenting and Reporting Findings

We write findings so that someone outside the test session can reproduce the issue, understand the risk, and decide what to do next. Documentation should support remediation, future development, and regulatory review without forcing each audience to reconstruct the investigation.

Use stable identifiers and version-controlled records. Preserve the tested configuration and distinguish confirmed findings from observations, assumptions, and untested concerns.

• Risk Identification: Describe the affected hardware, software, interface, or supporting service. State how the issue was identified, what access is needed, and what it could change or expose. Document both the device-level consequence and the possible patient-safety effect, with links to the relevant risk entries.

• Vulnerability Assessment Details: Record the methods used, including penetration testing, static analysis, dynamic analysis, or other techniques. Include test conditions, software and hardware versions, configuration, outcomes, and evidence. If a fix was applied during testing, preserve the before-and-after records rather than replacing the original result.

• Recommendations for Improvements: Specify actions that address the demonstrated weakness. Prioritize them using the documented risk method and assign a proposed implementation timeline. Separate immediate containment from permanent remediation, and explain when a design or development-process change is needed instead of a local code correction.

• Action Plan and Remediation Strategies: Name an accountable owner, required resources, target date, and closure evidence for each action. Record implementation decisions and obstacles that affect completion. Where remediation is deferred, document the rationale, interim controls, and the authority responsible for accepting the remaining risk.

• Regulatory Compliance Evidence: Map findings and their dispositions to applicable requirements, security controls, and risk records. Show how the audit supports the FDA's expectations for risk management and testing. Include how monitoring and future updates will address concerns that cannot be settled by a one-time test.

• Feedback Loop for Future Development: Identify recurring causes, not just individual defects. Feed lessons into coding rules, architecture reviews, test coverage, and supplier decisions. If the same weakness can appear in another product or branch, assign an action to investigate rather than assuming the current fix resolves it everywhere.

• Stakeholder Communication: Prepare summaries suited to regulatory reviewers, partners, customers, and internal leadership. Explain the risk, current status, and required actions without making unsupported assurances. Keep detailed exploit information restricted where appropriate, while giving affected parties enough information to act safely.

High-level control claims rarely give a reviewer enough detail to judge adequacy. For an audit, that means checking the chain from control to requirement to test case to result.

The report should also state what remains unresolved. A list of documents is not a residual risk conclusion, and a clean executive summary should not obscure open findings.

We consider the record usable when an engineer can act on it, a risk owner can evaluate it, and a reviewer can follow its evidence without an oral explanation.

Step 9: Developing an Action Plan

We turn the audit report into assigned work. Every finding needs a disposition, an owner, a due date, and a definition of closure. Without those elements, an audit can produce an accurate description of problems while leaving the device unchanged.

The plan should address immediate exposure and the underlying causes. A temporary restriction may reduce risk while engineering develops a permanent fix, but the two actions need separate tracking.

• Immediate Steps for Critical Vulnerabilities: Address findings with the highest security and patient-safety consequences first. Available actions may include patches, software updates, replacement of default passwords, or disabling unnecessary services. Assess the operational effect before applying a change to fielded devices, and document any interim instructions users need.

• Classification and Prioritization: Use severity, exploitability, potential harm, and remediation complexity to plan the work. High-severity issues that can be fixed quickly deserve prompt attention, but difficult high-risk issues should not fall behind easy low-risk tasks. Record dependencies and escalation points when a fix needs a larger design change.

• Long-Term Security Enhancement Strategies: Identify changes to architecture, encryption configuration, communication protocols, and authentication where local fixes are insufficient. Include improvements to secure coding, development gates, and release processes. Link each improvement to the weakness it addresses so the plan does not become an unrelated security wish list.

• Staff Training and Awareness Programs: Assign training that addresses the causes found in the audit. Engineers and developers may need work on control specifications or secure implementation; sales and customer support may need guidance on recognizing threats, handling data, and escalating reports. Tailor the content to the decisions each role actually makes.

• Regular Review and Updates: Set a review cadence and define events that reopen the plan, such as a new vulnerability, architecture change, or supplier support change. Reassess affected risks and test coverage. Keep the action plan aligned with current builds and fielded versions rather than only the version originally audited.

• Stakeholder Communication: Plan customer notifications, patch instructions, regulatory communications, and exchanges with the security community where appropriate. Identify the person who approves each message and the information needed before release. Explain required actions and limitations clearly, especially when users must change configuration or schedule an update.

For each technical fix, define the retest before declaring the work complete. The closure criterion should describe observable behavior or evidence, not merely “code updated.” Record which build contains the correction and which released versions remain affected.

We also distinguish routine remediation from issues that warrant corrective and preventive action under the manufacturer's quality process. Repeated failures or process breakdowns may require more than closing a single defect. Link those actions to the risk file and relevant development records.

The plan is complete when the manufacturer can explain what is being fixed now, what remains open, why the remaining risk is acceptable or requires escalation, and how each decision will be revisited. That is a more useful outcome than a long list of recommendations with no accountable owner.

Step 10: Continuous Improvement and Staff Training

We treat the audit as an input to the next development cycle and the ongoing post-market process. Findings should change how people design, review, release, and support the device. If the same gap returns unchanged in the next audit, the corrective work did not reach its cause.

Training extends beyond engineering and IT. Sales, customer support, administration, and leadership make decisions that affect security, data handling, and incident response. Each group needs practical guidance within its responsibilities.

• Cybersecurity Training Programs: Give engineers and developers training in secure coding, threat modeling, vulnerability assessment, and testing. Train customer-facing staff to recognize social engineering, handle customer data safely, and describe security features accurately. Administrative and executive staff should understand policy, escalation duties, incident response, and the legal and reputational effects of security decisions.

• Regular Training Sessions: Update training as threats, products, and procedures change. Workshops, webinars, e-learning, and outside instruction can all work, but attendance alone is weak evidence of learning. Ask participants to apply the material to their own responsibilities and review where the exercise exposes uncertainty.

• Real-world Simulations and Drills: Use controlled phishing exercises and incident-response drills to test behavior, not just recall. Include communication, escalation, containment, and recovery decisions. Record delays, missing information, and unclear ownership. Assign improvements after the exercise and check whether the next drill shows those gaps have closed.

• Incentivize Security Innovations: Recognize employees who identify weaknesses and propose workable improvements. Recognition programs, bonuses, or competitions can support participation, provided they do not reward finding counts over useful results. Staff should be able to raise concerns without needing to prove an exploit or fear blame for reporting a mistake.

• Embed Cybersecurity in the Company Culture: Leadership should make security visible in product planning, staffing, and release decisions. Explain its connection to patient safety and the company's obligations. Recognition matters, but allocating time for remediation and accepting justified schedule changes shows whether security has real decision-making weight.

• Cross-functional Cybersecurity Committees: Bring engineering, regulatory staff, sales, customer support, and other relevant groups together to resolve shared issues. Give the group authority to assign owners and escalate decisions. Use it to connect field reports, development changes, and customer communications rather than creating another meeting that only repeats status.

• Continuous Feedback Loop: Provide a way for employees to report confusing policies, impractical controls, and training gaps. Review that feedback with the people who own the process. Explain what will change and what will not, so staff can see that reporting a problem produces a decision.

We use audit results to choose the next improvement priorities. Repeated documentation gaps call for better requirements and review practices. Repeated implementation defects call for changes to coding, design review, or test coverage. Training should support those changes, not serve as the default answer to every finding.

Maintain records of the improvements, their owners, and the evidence that they worked. The goal is not to claim that everyone is security-aware. It is to show that the organization can detect a problem, make a defensible decision, correct it, and carry that lesson into the next release.

Audit Phases at a Glance

Conclusion

A medical device security audit should leave us with evidence, not just a list of concerns. We need to know which interfaces an attacker can reach, which controls resist that access, and what a failure could mean for a patient. That work starts during design, includes third-party software and supporting systems, and continues after release. A clean report does not replace ongoing vulnerability monitoring, patching, or staff training.

Saying a device requires authentication is not enough. We need the requirement, the configured control, the test case, and the result linked together so a reviewer can follow the evidence. Reviewing a documented update process is no substitute for testing whether the device actually rejects unauthorized code.

This is the part teams skip: closing the audit. Each finding needs an owner, a remediation decision, a target date, and evidence supporting closure or residual risk acceptance. We carry those decisions into the risk file and use retesting to check whether the fix addresses the attack path.

We judge an audit by whether it improves those decisions and exposes unsupported security claims. Regulatory alignment matters, but the practical goal is a device the manufacturer can defend, maintain, and support throughout its lifecycle, with patient safety driving the priorities.

Check out our medical device cybersecurity FDA premarket submission package.

How Blue Goat approaches this

We audit the device’s architecture, software, and network interfaces, then prioritize findings by exploitability and potential impact. Our engineers, many with prior US military red team experience, turn those findings into specific remediation actions.

We check evidence, not just security claims. Vague control descriptions and unenforced controls are different gaps: one needs testable specifications; the other needs a control the device actually enforces.

Our audits and premarket reviews align with the FDA’s February 3, 2026 final guidance, “Cybersecurity in Medical Devices.” We identify submission gaps without promising clearance. If the FDA raises cybersecurity deficiencies after our submission, we resolve them at no additional cost. Learn more about our FDA premarket cybersecurity services.

FAQ

What is the primary goal of a medical device security audit?

The primary goal is to systematically evaluate and enhance the cybersecurity posture of a medical device across its lifecycle. This ensures patient safety, protects sensitive health information, and maintains operational continuity against emerging cyber threats.

Which FDA guidance applies to medical device cybersecurity audits?

Medical device cybersecurity audits should align with the FDA's February 3, 2026 final guidance. This guidance outlines the agency's expectations for cybersecurity in medical devices submitted for premarket review.

Who should be involved in a medical device security audit team?

A specialized team should include cybersecurity experts, software developers, hardware engineers, regulatory and compliance specialists, and user experience (UX) researchers. This multidisciplinary approach ensures all aspects of device security and usability are addressed.

What areas does a complete audit scope cover?

A complete audit scope covers hardware components, software (including open-source elements), network capabilities, interoperability security, data storage and transmission, and adherence to relevant regulatory standards like the FDA's guidance.

Why is early inclusion of devices in the audit process important?

Early inclusion allows for the identification and remediation of potential vulnerabilities during the design and development phases. This proactive approach strengthens the device's overall security posture before it reaches the market.

How does a medical device security audit address data privacy?

The audit assesses how data is collected, stored, transmitted, and disposed of, emphasizing encryption, strong access controls, and secure data deletion practices. This ensures compliance with regulations like HIPAA and protects patient health information.