FDA cybersecurity requirements for medical devices are no longer a future concern they are actively enforced during premarket review and submission teams are increasingly encountering cybersecurity related review deficiencies. Since October 2023, the FDA has been issuing Refuse to Accept (RTA) letters for premarket submissions lacking adequate cybersecurity documentation. In June 2025, the agency published updated final guidance that raised the bar further including making cybersecurity an independent grounds for denial of market authorization.
This post is written for regulatory and quality professionals at SaMD companies who are past the basics and need to understand where the practical difficulties lie in 2026 particularly around the 2025 guidance updates, the eSTAR documentation package, and the intersection of cybersecurity with 510(k) substantial equivalence.
The Legal Baseline: Section 524B and What It Actually Requires
Section 524B of the FD&C Act, enacted via the Consolidated Appropriations Act of 2023 (effective March 29, 2023), gives FDA explicit statutory authority to require cybersecurity documentation as a condition of premarket submission acceptance not merely as guidance. The threshold question is whether your device qualifies as a “cyber device”: software validated, installed, or authorized by the sponsor; ability to connect to the internet (directly or indirectly); and technological characteristics that could be vulnerable to cybersecurity threats.
For SaMD running on cloud infrastructure, mobile platforms, or general purpose computing environments, the answer is almost always yes. The 2025 guidance clarified that indirect internet connectivity including devices that connect via a host system or network falls within scope.
Practical note: If your SaMD transmits data to a cloud based inference engine or communicates with an EHR via API, it is a cyber device under Section 524B. There is no carve out for software only devices or devices that rely on a third party for connectivity.
What the June 2025 Guidance Changed and Why It Matters
The 2025 guidance is not a cosmetic update to the September 2023 guidance. Several changes have direct operational consequences:
1. Cybersecurity is now a standalone denial ground
Previously, cybersecurity deficiencies were assessed as part of the broader safety and effectiveness determination. Under the 2025 guidance, a device can be denied market authorization on cybersecurity grounds alone, even if it meets all other requirements. For SaMD teams, this means cybersecurity documentation can no longer be treated as a compliance annex it carries the same weight as clinical evidence.
2. Predicate device cybersecurity comparison in 510(k) submissions
This is arguably the most consequential change for SaMD companies pursuing the 510(k) pathway. The 2025 guidance explicitly states that a device with materially increased cybersecurity risk compared to its predicate device may be found not substantially equivalent. In practice, this means:
- If your SaMD has expanded connectivity or new data sharing capabilities relative to the predicate, you need to address the cybersecurity delta in your submission not just the functional equivalence argument.
- A predicate device cleared before mandatory cybersecurity requirements (i.e., before March 2023) offers limited protection. The FDA will assess the current device against current cybersecurity expectations, not the predicate’s documentation standard.
- Teams relying on legacy predicates with minimal cybersecurity documentation should anticipate additional reviewer scrutiny and plan accordingly.
In recent SaMD submissions reviewed by FDA following the implementation of Section 524B requirements, cybersecurity related deficiencies have frequently been raised in Additional Information (AI) requests during 510(k) review.
One common scenario involves SaMD systems that introduce expanded cloud connectivity relative to their predicate device. In these cases, FDA reviewers have requested:
- A comparative cybersecurity risk analysis between the predicate and subject device
- Updated threat models reflecting the new connectivity architecture
- Documentation explaining security controls mitigating new attack surfaces
For example, in one 2024 SaMD submission involving a cloud based clinical decision support system, FDA reviewers requested additional documentation after identifying that the subject device introduced remote API based connectivity not present in the predicate device. The sponsor was required to submit an updated threat model, revised architecture documentation, and additional penetration testing results before the review could proceed.
These examples illustrate that cybersecurity differences between the predicate and subject device must be explicitly addressed, rather than assumed to be covered by the substantial equivalence argument.
3. The 12 document eSTAR cybersecurity package
The 2025 guidance specifies the 12 cybersecurity documents required for eSTAR submissions. This is a material change from the prior guidance, which described documentation requirements at a higher level of abstraction. The 12 documents cover:
- Cybersecurity management plan (including post-market monitoring and patching timelines)
- Software Bill of Materials (SBOM) complete inventory including third party and open source components
- Threat model and security risk assessment
- Security architecture documentation
- Evidence of security testing (penetration testing, vulnerability scanning)
- Labeling with cybersecurity information
- Six additional documents covering the Secure Product Development Framework (SPDF), authentication and access controls, cryptography, data integrity, and software maintenance processes
The FDA’s eSTAR submission template operationalizes cybersecurity documentation requirements described in the June 2025 guidance. While the guidance describes cybersecurity expectations conceptually, the eSTAR template organizes these expectations into specific documentation modules typically covering:
- Cybersecurity Risk Management Plan
- Secure Product Development Framework (SPDF) documentation
- Threat Modeling documentation
- Security Architecture description
- Software Bill of Materials (SBOM)
- Security Risk Assessment aligned with ISO 14971
- Security Control Implementation documentation
- Security Testing evidence (vulnerability assessment, penetration testing)
- Authentication and Access Control design
- Cryptography implementation details
- Update and Patch Management process
- Cybersecurity Labeling and customer security documentation
Manufacturers should always confirm documentation expectations using the latest FDA eSTAR submission template, as the template may evolve with periodic FDA updates.
4. Reasonable assurance of cybersecurity what it means in practice
The 2025 guidance requires manufacturers to demonstrate “reasonable assurance of cybersecurity” explicitly not just as a component of a general safety argument. The FDA has not defined this phrase with a bright line test, which creates practical uncertainty. Based on the guidance text and FDA’s review behavior post 2023, “reasonable assurance” appears to require:
- A documented Secure Product Development Framework (SPDF) that runs through the QMS design controls not a retrospective assessment.
- Threat modelling that is device specific and reflects the actual deployment environment, not a generic threat library.
- Post-market vulnerability monitoring with defined SLAs the guidance references a 30 day customer notification window for vulnerabilities requiring action.
- SBOM completeness that extends to transitive dependencies, not just direct third party libraries.
Where teams commonly fall short:
SBOMs that list direct dependencies but miss transitive open source components; threat models completed post design rather than integrated into design controls; and post market monitoring processes that exist on paper but have no designated owner or tooling.
SaMD Specific Considerations the Guidance Does Not Fully Address
The FDA guidance is written to cover both hardware and software devices. SaMD teams operating on cloud infrastructure or delivering AI/ML based diagnostic functions face several requirements that the guidance leaves partially unresolved:
Cloud hosted SaMD and the SBOM challenge
For SaMD deployed on cloud infrastructure (AWS, Azure, GCP), the SBOM boundary is genuinely ambiguous. The FDA guidance requires an SBOM for the device, but does not specify how to handle cloud native dependencies container base images, managed services, runtime dependencies that are not under the manufacturer’s direct control. In practice, FDA reviewers have accepted SBOMs that clearly delineate manufacturer controlled software from infrastructure dependencies, with documented rationale for the boundary. This should be addressed explicitly in the cybersecurity management plan.
AI/ML components and continuous learning
SaMD incorporating AI/ML models faces an additional layer of cybersecurity risk beyond what the Section 524B framework was originally designed for: model integrity, adversarial input resilience, and the cybersecurity implications of post-market model updates. The IMDRF published updated guidance on Good Machine Learning Practice (GMLP) in 2025 (IMDRF/SaMD WG/N81 FINAL 2025), which regulators including FDA reference. Teams with continuously learning algorithms should ensure their cybersecurity architecture documentation addresses model integrity and update authentication, not just network layer security.
Key cybersecurity concerns for AI enabled SaMD include:
- model integrity and tampering
- adversarial input attacks
- training data poisoning
- unauthorized model updates
Reference:
- International Medical Device Regulators Forum
- IMDRF Good Machine Learning Practice (GMLP)
Security Testing expectations for SaMD
Typical evidence expected in cybersecurity submissions includes:
- vulnerability assessment reports
- penetration testing evidence
- authentication and access control validation
- secure communication verification (TLS/HTTPS)
- API security testing
These testing activities should align with the device software lifecycle defined in:
- IEC 62304
In cybersecurity assessments conducted for AI enabled SaMD platforms, testing frequently extends beyond traditional network and application security controls. For instance, in a recent security evaluation of a cloud based AI diagnostic platform, testing included:
- Validation of model update authentication mechanisms to prevent unauthorized model replacement
- Assessment of API endpoint security used for transmitting patient imaging data to the inference engine
- Testing of input validation controls to mitigate adversarial or malformed data submissions
- Verification of secure communication protocols (TLS encryption) between client applications and cloud inference services
These additional validation activities help ensure that both the software infrastructure and AI model lifecycle meet cybersecurity expectations under FDA guidance.
Legacy devices and the guidance gap
The 2025 guidance explicitly states it does not address legacy devices that cannot receive patches or updates. Manufacturers with fielded devices in this category are in a regulatory grey zone. The FDA has indicated that such manufacturers should engage via the Q Submission (Pre-Sub) program but the guidance provides no safe harbour. Teams with legacy SaMD in active use should conduct an internal risk assessment and consider proactively engaging FDA before the issue surfaces in a post market surveillance context.
Relevant Standards: Where They Sit in the Submission
The 2025 guidance references several consensus standards that FDA reviewers treat as baseline expectations. Note the distinction between recognized consensus standards and guidance documents:
- ANSI/AAMI SW96 Medical device security risk management. Now a baseline expectation from FDA reviewers; industry adoption has lagged the regulatory expectation.
- AAMI TIR57 Security risk management guidance, used alongside ISO 14971.
- IEC 62304 Medical device software lifecycle. Cybersecurity activities, including threat modelling and secure coding, should be integrated into the 62304 lifecycle documentation.
- IEC 81001-5-1 Health software and IT systems cybersecurity across the product lifecycle. The international counterpart to the FDA framework, relevant for companies pursuing multi market approval.
- ISO 14971 Cybersecurity risk should be addressed within the ISO 14971 risk management framework, not in a parallel process.
International Context EU and Multi-Market Implications
For SaMD companies with EU market ambitions, the EU Cyber Resilience Act (CRA) which entered into force in December 2024 introduces additional cybersecurity obligations for products with digital elements, including software only medical devices. The CRA requirements and EU MDR Article 5 technical documentation requirements are not identical to the FDA framework, and teams pursuing parallel US/EU submissions should map the differences explicitly rather than assuming harmonisation.
The IMDRF framework (N81, 2025) provides a common reference point across FDA, EU, Health Canada, and TGA. Building a compliance programme around IMDRF N81 as the structural backbone, with market specific additions for FDA eSTAR requirements and EU CRA obligations, is generally more efficient than maintaining separate compliance tracks.
Practical Priorities for SaMD Teams in 2026
Based on where regulatory teams commonly encounter friction in submissions and pre-submission interactions:
- Use the Q Submission (Pre-Sub) program before filing if you have any ambiguity about your cybersecurity approach particularly around SBOM scope, deployment environment boundaries, or AI/ML components. An FDA pre-Sub meeting is one of the most cost effective ways to surface reviewer expectations before investing in a full submission package.
- Build your threat model into design controls from the outset, not as a retrospective activity. FDA reviewers are increasingly able to identify threat models that were completed post design they lack the design decision rationale that genuine SPDF integration produces.
- Assign a named owner for post-market vulnerability monitoring before submission, with a documented process for NVD monitoring, severity assessment, and customer notification. The 30 day notification window in the guidance requires a functional process, not a paper commitment.
- Verify your SBOM tooling captures transitive dependencies. Tools that only scan package manifests (package.json, requirements.txt) commonly miss dynamically linked libraries and container base image components.
- If you are pursuing a 510(k) and your SaMD has expanded connectivity or data sharing features relative to the predicate, prepare a specific cybersecurity delta analysis do not assume the substantial equivalence argument covers it implicitly.
- Review the 12 document eSTAR cybersecurity package against your current documentation and identify gaps early. RTA letters on cybersecurity grounds extend review timelines significantly.
How NexorTest Technologies Supports SaMD Cybersecurity Compliance
NexorTest Technologies is an ISO/IEC 17025 accredited medical device testing and regulatory consulting firm, with offices in Bengaluru and Sharjah. We support SaMD manufacturers and digital health companies across the FDA, EU MDR, CDSCO, MHRA, and TGA regulatory pathways.
Our cybersecurity services for SaMD companies cover the full premarket submission requirement set: SBOM generation and gap analysis, threat modelling integrated into QMS design controls, security testing (penetration testing and vulnerability assessment), and documentation support for 510(k), PMA, and De Novo submissions including the 12 document eSTAR cybersecurity package.
We also support post market cybersecurity programme builds establishing vulnerability monitoring processes, patch management documentation, and customer notification workflows that satisfy the ongoing obligations under Section 524B.
Contact us: To discuss your SaMD cybersecurity submission requirements, contact NexorTest
References
- FDA, Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions, June 2025 (Final Guidance)
- FDA, Section 524B of the FD&C Act, Consolidated Appropriations Act 2023
- IMDRF, Software as a Medical Device (SaMD) N81 FINAL:2025
- IEC 62304:2006+AMD1:2015, Medical device software Software life cycle processes
- ANSI/AAMI SW96:2023, Standard for medical device security Security risk management
- IEC 81001-5-1:2021, Health software and health IT systems safety, effectiveness and security
- EU Cyber Resilience Act (Regulation (EU) 2024/2847), entered into force December 2024
Meet Our Regulatory Expert
Dr.Pabbisetty PBS Kumar
CHIEF COMPLIANCE OFFICER
NEXORTEST TECHNOLOGIES
