FDA cybersecurity and IEC 62304
What section 524B and FDA's premarket cybersecurity guidance expect from a connected device, which evidence a cloud platform can hand you for its layer, and which work stays with your team.
Short answer
The FDA regulates your device, and the cloud your device depends on is part of the system you submit. For a cyber device, section 524B requires a plan to address postmarket vulnerabilities, processes that provide reasonable assurance of cybersecurity, and a software bill of materials. A platform can supply audited controls and ready documentation for its layer. Your threat model, your risk assessment and your submission stay with you. Platforms are not FDA cleared or approved. Your device is the regulated product.
Section 524B of the FD&C Act applies to premarket submissions for cyber devices. A device is a cyber device if it meets all three criteria:
The sponsor must then provide three things:
FDA's guidance, Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions, explains what reviewers expect. FDA states that manufacturers are responsible for identifying cybersecurity risks in their devices, including risks tied to cloud infrastructure. The guidance has been revised since 2023, so check the current version on fda.gov before you submit.
| Submission element | What the platform layer can supply | What stays with you |
|---|---|---|
| Threat model | Platform architecture and data flows for the cloud layer | The device-level threat model covering the device, its connection and your applications |
| Cybersecurity risk assessment with a scoring method | The platform cybersecurity risk assessment (BioT CS-002) | Your device risk assessment, with platform risks referenced |
| SBOM with NTIA minimum elements, support level and end-of-support dates | The platform SBOM, issued with every platform release | The SBOM for your device software and any code you deploy on the platform |
| Assessment of known vulnerabilities, including CISA's Known Exploited Vulnerabilities catalog | Static analysis and software composition analysis in BioT's CI/CD pipeline, with the issue detail | The same for your components |
| Architecture views: global system, multi-patient harm, updateability and patchability, security use cases | Platform architecture documentation | Your system-level views |
| Penetration testing, with tester independence, scope and methods | Independent penetration testing of the platform | Testing of your device and your applications |
| Cybersecurity management plan: monitoring, patch timelines, coordinated disclosure | The platform cybersecurity management plan (BioT CS-001) | Your device plan and your customer communication |
| Security labeling | Platform facts to reference | Your labeling |
BioT maps its platform documentation to FDA's eSTAR template, version 7.0, so your regulatory team can reference each document by ID. eSTAR version 6.2 was retired on August 3, 2026.
| Document | ID | Use in your submission |
|---|---|---|
| Software Requirements Specification | SRS-0001 | Software documentation |
| Software Design Description | SDD-0001 | Software documentation |
| Software life cycle procedure | QDC-00013 | Software development process evidence |
| Risk table | QRM-0003 | Software risk management |
| Test description and test report | STD-001, STR-001 | Verification and validation |
| Software version description | SVD-0001 | Release identification |
| Cybersecurity Management Plan | CS-001 | Cybersecurity management plan and patch timelines |
| Cybersecurity Risk Assessment | CS-002 | Cybersecurity risk assessment |
| Cybersecurity Report | CS-003 | Cybersecurity controls, architecture and testing |
| Software bill of materials, off-the-shelf software and vulnerability detail | SBOM, OTS-001 | SBOM, off-the-shelf software and known vulnerabilities |
Human factors content and every device-specific section remain yours. The full mapping, with eSTAR section numbers, is in the eSTAR submission support documentation.
IEC 62304 governs the life cycle of your medical device software. You classify each software item by the harm it could contribute to: Class A, no injury or damage to health is possible; Class B, non-serious injury is possible; Class C, death or serious injury is possible. The class sets how much process evidence you need. Third-party software, known as software of unknown provenance (SOUP), needs defined requirements, a risk analysis and a rationale for its use.
BioT maintains an IEC 62304-compliant Design History File for the platform. It contains the software development plan, risk analysis, requirements and their review, design and its review, test plan, test description, test readiness review, test report, off-the-shelf software validation, full traceability, the software version description, the cybersecurity report and the SBOM. BioT documents the file as prepared to support software up to Class C.
The file is stand-alone. You can reference it, integrate it into your own Design History File, or extend it with your device requirements, risks and tests. Your software classification remains your decision.
Assess each platform release under your own change control and update your Design History File and ISO 14971 risk file where needed. BioT supplies release notes, an updated Design History File and an updated SBOM. Decide with your regulatory advisors which changes affect your submission.
Custom code you deploy on the platform is your software. Develop it under your IEC 62304 procedure, keep its SBOM, and scan its repositories in your CI pipeline. It is not part of the platform SBOM.
| Certifications and attestations | HITRUST r2. SOC 2 Type II covering the Security, Availability, Confidentiality and Privacy criteria. ISO 27001 and ISO 27799 for the information security management system. ISO 13485 for the quality management system. Reports are shared under NDA. |
| Encryption | AES-256 at rest through AWS KMS. HTTPS only in transit, TLS 1.2 or higher. Devices connect over MQTT through AWS IoT Core with mutual X.509 certificate authentication. |
| Network | AWS WAF inspects user and API traffic. |
| Access control | Two layers. API permissions decide which calls a user can make. Attribute-based access control then checks every request to decide which data the user can reach. PHI fields are flagged per field and are visible only to the patient and to caregivers in the same organization. The manufacturer sees non-PHI data across organizations. |
| Authentication | Multi-factor authentication with a one-time code by email or SMS. Passwordless one-time-code login. Enforced password policy. |
| Audit logging | User activity is logged and audited, and logs are protected from tampering, including by privileged users. |
| Vulnerability management | Static analysis and software composition analysis run in the CI/CD pipeline. Independent penetration testing of the platform. |
| Backups | Production backups kept daily for 30 days, weekly for 12 weeks, monthly for 12 months and yearly for 10 years. |
| Deployment and contracts | A dedicated environment for production, either in a BioT-managed AWS account or in your own AWS account. Hosting in the US, EU and Asia. BAA and DPA in both models, and a published subprocessor list. |
When a hospital or a reviewer asks whether the evidence covers your data path, ask which components and regions each certification and attestation covers, and map them to your architecture. That is the question that comes up most in security reviews.
BioT customers have achieved FDA clearance and CE marking on the platform. Those clearances belong to the customers and their devices.
BioT estimates the direct certification and documentation cost of a do-it-yourself medical device cloud at about $945,000 over three years:
| Item | Three-year cost |
|---|---|
| HITRUST r2 | $341,000 |
| SOC 2 Type II | $201,000 |
| Design History File | $132,000 |
| Vulnerability scanning | $78,000 |
| ISO 27001 | $55,000 |
| SBOM | $51,000 |
| ISO 13485 | $45,000 |
| Penetration testing | $42,000 |
| Total | $945,000 |
Time matters as much as cost. SOC 2 Type II and HITRUST r2 each require 18 to 24 months of documented operating history before certification is granted. See the compliance page for the full comparison.
No. Cloud platforms are not cleared or approved. Your device is the regulated product. BioT provides certified, audited infrastructure and documentation that you reference in your submission.
The platform layer: its controls, its certifications and attestations, its SBOM, its vulnerability scanning and penetration testing, and its cybersecurity documentation. The device-level threat model, risk assessment and testing remain your work.
No. Code you write and deploy is your software. Keep its SBOM and scan it in your own pipeline.
Assess each release under your change control. Changes to functions that serve your intended use, such as alerts or algorithms, deserve the closest review. BioT supplies release notes, an updated Design History File and an updated SBOM. Confirm the reporting decision with your regulatory advisors.
Yes, by reference. Each platform document has an ID mapped to eSTAR sections, and you can reference, integrate or extend it.
Related: compliance and certifications, cloud infrastructure for SaMD, and EHR integration.
2026 All rights reserved
Last updated on:
August 5th, 2026 VER .17