On this page
Published: July 23, 2026
Key Takeaways
- FDA premarket cybersecurity deliverables are QMS outputs, not a parallel file - the controlling Feb 3, 2026 guidance is literally titled 'Quality Management System Considerations and Content of Premarket Submissions.'
- Under QMSR (effective Feb 2, 2026), ISO 13485:2016 is incorporated by reference; design controls now sit in ISO 13485 Clause 7.3, not the old 21 CFR 820.30.
- Three anchors carry almost the entire cybersecurity file: design and development (7.3), risk management (7.1 + ISO 14971), and measurement/improvement (8.2.2 complaints, 8.5 CAPA, 7.5.4 servicing).
- Every deliverable has a defined home: DHF for requirements, architecture, SAST, and pen test; risk management file for threat model and risk assessments; DMR and purchasing for SBOM, MDS2, and labeling.
- The premarket file is not a snapshot - it is the running record. Section 524B postmarket obligations execute against the same DHF, risk file, and CAPA process, so a well-integrated QMS is also your postmarket engine.
FDA premarket cybersecurity deliverables are quality-system outputs, not a parallel stack. Under the QMSR (effective Feb 2, 2026), each artifact lands in a specific ISO 13485 clause - design controls (7.3), risk management (7.1 + ISO 14971), or measurement/improvement (Clause 8) - so the same records that support your submission also run your Section 524B postmarket program.
Quality and regulatory teams are right to scrutinize anything that touches the design history file. The concern usually takes one of two forms: outsourced deliverables will arrive as a separate stack of PDFs that live outside the quality system, or the method behind the submission will not be something the QMS can carry forward for the life of the device. Both worries rest on a premise the current FDA framework has retired. Cybersecurity is no longer a bolt-on to the submission - it is an output of the quality system itself.
Table of Contents
Why this matters
On February 2, 2026, the FDA's final rule amending 21 CFR Part 820 took effect. The revised Part 820 - the Quality Management System Regulation (QMSR) - incorporates ISO 13485:2016 by reference. For US manufacturers, ISO 13485 and the QMSR are now effectively one framework. One day later, on February 3, 2026, the FDA issued the final guidance Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions. The title is not incidental: the guidance is explicit that documentation "related to the ongoing requirements of the QMSR may be one source of documentation to include as part of the premarket submission," and it describes "how the QMSR can be leveraged to demonstrate these performance outputs."
Add Section 524B of the FD&C Act on top of that, and the picture is clear. Cybersecurity is a statutory requirement, its evidence lives in your quality system, and the same records you file at premarket are what carry your postmarket obligations. Recognized consensus standards - ISO 14971, ANSI/AAMI SW96, AAMI TIR57, IEC 81001-5-1, and IEC 62304 - are the language the artifacts are written in.
What the framework actually says
The QMSR keeps ISO 13485 as the core of the quality system and retains only a few FDA-specific sections on top of it, notably §820.35 (control of records) and §820.45 (device labeling and packaging). Three anchor points in that framework carry almost the entire cybersecurity file:
- Design and development, ISO 13485 Clause 7.3. Design inputs, outputs, review, verification, validation, transfer, and change control. The home for security requirements, architecture, and testing evidence.
- Risk management, ISO 13485 Clause 7.1 with ISO 14971. The home for the threat model, cybersecurity risk assessment, and residual-risk decisions.
- Measurement, analysis and improvement, Clause 8. Complaints (8.2.2), CAPA (8.5), and servicing (7.5.4). The home for the postmarket cybersecurity management plan and coordinated disclosure.
The FDA ties these together through the Secure Product Development Framework (SPDF) - a set of processes that reduce vulnerabilities across the lifecycle and that, in the FDA's words, "can be integrated with existing processes for product and software development, risk management, and the quality system at large."
Where every deliverable lives
The design history file and risk management file do most of the work, with the device master record and purchasing picking up the rest. The table below maps each premarket cybersecurity deliverable from the FDA's 2026 guidance to its home in an ISO 13485 / QMSR-aligned QMS.
| Deliverable | ISO 13485 Clause | QMS Record Type | 524B / FDA Tie-in |
|---|---|---|---|
| Security Requirements & Control Coverage | 7.3.3 | Design input (DHF) | 524B(b)(1) secure design |
| Security Architecture Views (global, multi-patient-harm, updateability, security-use-case) | 7.3.4 | Design output (DHF) | 524B(b)(1); guidance §V.A.3 |
| Static Application Security Testing (SAST) | 7.3.6 | Design verification (DHF) | Guidance §V.B.2 |
| Penetration Test Plan, Cases, Report | 7.3.2, 7.3.6 | Verification planning + record (DHF); findings → CAPA 8.5 | Guidance §V.B.4 |
| Assessment of Unresolved Anomalies | 7.3.6 | Design verification record (DHF) | Guidance §V.B.5 |
| Threat Model | 7.1 (with ISO 14971) | Hazard identification input (RMF) | Guidance §V.A.2 |
| Cybersecurity Risk Assessment | 7.1 (with ISO 14971) | Security risk record bridged to safety (RMF) | Guidance §IV |
| Interoperability Risk Assessment | 7.1 (with ISO 14971) | Connected-use risk record (RMF) | Guidance §V.A.4 |
| Risk Management Report | 7.1 (with ISO 14971) | Residual-risk acceptability record (RMF) | Guidance §IV |
| SBOM | 7.4, 7.5.1 | Controlled record (DMR) | 524B(b)(3); §820.35 |
| Component Support & End-of-Support | 7.4 | Supplier-controlled information | 524B(b)(2) postmarket |
| MDS2 | 7.5.1 | Labeling / communication record (DMR) | Guidance §VI |
| Interoperability Labeling | 7.3.4, 7.5.1 | Labeling record (DMR) | Guidance §V.A.4 |
| Cybersecurity Management Plan | 4.2, 8.2 | Process record | 524B(b)(2) postmarket |
Reading the map: requirements, architecture, and controls are design inputs and outputs; SAST and penetration testing are design verification; the threat model and risk assessments populate the risk management file; labeling, MDS2, and SBOM belong to the device master record and purchasing.
[KEY REQUIREMENT] How these records attach in eSTAR v7.0
eSTAR v7.0 (mandatory for 510(k) as of Oct 1, 2023, and required for most De Novo submissions from Oct 1, 2025) surfaces cybersecurity as a dedicated section that pulls directly from the QMS records above. At submission time, each deliverable is attached to a specific eSTAR node - the QMS record ID travels with it so the file stays traceable:
- Cybersecurity Management Plan - eSTAR §Cybersecurity > Security Risk Management Plan. Source: QMS process record (Clause 4.2 / 8.2).
- Threat Model + Cybersecurity Risk Assessment + Risk Management Report - eSTAR §Cybersecurity > Security Risk Assessment and Risk Management Report. Source: risk management file (Clause 7.1 / ISO 14971).
- Security Architecture Views (global system, multi-patient harm, updateability, security-use-case) - eSTAR §Cybersecurity > Architecture Views. Source: DHF design outputs (Clause 7.3.4). Attach all four as separate PDFs.
- SBOM + Vulnerability Assessment + Component Support/EOS - eSTAR §Cybersecurity > Software Bill of Materials. Source: DMR / purchasing records (Clause 7.4, 7.5.1). SBOM in SPDX or CycloneDX; VEX as companion file.
- SAST report + Penetration Test Plan/Report + Assessment of Unresolved Anomalies - eSTAR §Cybersecurity > Cybersecurity Testing. Source: DHF verification records (Clause 7.3.6).
- Security Requirements & Control Coverage - eSTAR §Cybersecurity > Security Controls. Source: DHF design inputs (Clause 7.3.3).
- Interoperability Risk Assessment + Interoperability Labeling - eSTAR §Cybersecurity > Interoperability and §Labeling. Source: risk management file + DMR.
- MDS2 - eSTAR §Labeling (customer-facing security disclosure). Source: DMR labeling record.
Practical tip: name each PDF with its controlled document ID (e.g.
BGC-SRA-001-Rev-B_Security-Risk-Assessment.pdf) so the eSTAR attachment and the QMS record are one lookup, not two.
Ownership and control of the records
A guidance artifact only integrates if the manufacturer owns it and can keep it controlled over the life of the device. Well-authored deliverables carry a stable document ID and revision indicator, are written to sit as a design input, design output, verification record, or risk file entry (not a free-form report), and are delivered with editable source so the manufacturer can maintain them. Approval routing runs through the sponsor's normal design review and risk review gates, not a separate track.
How 21 CFR Part 11 applies to the DHF and RMF
When the DHF and risk management file are maintained electronically (which they almost always are), the records and their approvals fall under 21 CFR Part 11 - Electronic Records; Electronic Signatures. Part 11 does not change what the QMSR and ISO 14971 require; it governs how the electronic versions of those records must be trustworthy, reliable, and equivalent to paper.
Four Part 11 controls carry the weight for cybersecurity deliverables:
- §11.10(a) Validation - the eQMS, DHF/RMF repository, and any tool that generates a controlled record (SBOM generator, SAST platform, pen-test reporting tool) must be validated for intended use. Keep the validation record as an input to the design output that depends on the tool.
- §11.10(e) Audit trails - secure, computer-generated, time-stamped audit trails on every create, modify, and delete of a DHF or RMF record. The threat model, cybersecurity risk assessment, and verification reports must show who changed what and when, retained for the life of the record.
- §11.10(c) Record protection and retention - records are retained for the life of the device plus the retention period defined in the QMS. Backups, access controls, and integrity checks are Part 11 obligations, not just IT hygiene.
- §11.50 and §11.70 Electronic signatures - design reviews, risk-acceptance decisions, and verification approvals signed electronically must include the printed name of the signer, date and time, and the meaning of the signature (author, reviewer, approver), and must be linked to the record so they cannot be excised or copied.
Practical rule: if a cybersecurity deliverable is approved in the eQMS with an electronic signature, the eQMS's Part 11 validation package and audit trail are part of that record's defensibility. Author the deliverable, register it in the eQMS, route it through the same electronic signature workflow used for the rest of design controls, and the Part 11 posture is inherited rather than rebuilt.
Example Part 11 audit trail entries
See also: CAPA and Medical Device Cybersecurity, Types of 510(k): Traditional, Special, Abbreviated, and Q-Sub vs Pre-Sub: FDA Cybersecurity Guide.
Below is what a compliant audit trail should capture for a single cybersecurity deliverable (here, THM-014 Threat Model v1.2) as it moves from creation through modification to approval. Every row is computer-generated, time-stamped in UTC, tied to an authenticated user, and immutable.
| Timestamp (UTC) | Record ID | Version | Action | User (role) | Signature meaning | Reason for change | Prior value / hash | New value / hash |
|---|---|---|---|---|---|---|---|---|
| 2026-03-04 14:02:11Z | THM-014 | 1.0 | CREATE | j.rivera (Security Engineer) | Author | Initial threat model for Device X rev B | (none) | sha256:9f2c...a41 |
| 2026-03-11 09:47:33Z | THM-014 | 1.1 | MODIFY | j.rivera (Security Engineer) | Author | Added 3 STRIDE threats from DFD update | sha256:9f2c...a41 | sha256:b703...12e |
| 2026-03-12 16:20:05Z | THM-014 | 1.1 | REVIEW | s.okafor (Cyber Lead) | Reviewer | Technical review complete, no findings | sha256:b703...12e | sha256:b703...12e |
| 2026-03-14 11:08:52Z | THM-014 | 1.2 | MODIFY | j.rivera (Security Engineer) | Author | Incorporated reviewer comments on control mapping | sha256:b703...12e | sha256:c8d1...9f4 |
| 2026-03-15 13:45:19Z | THM-014 | 1.2 | APPROVE | m.chen (Design Assurance Mgr) | Approver | Approved for DHF; released to design review | sha256:c8d1...9f4 | sha256:c8d1...9f4 (locked) |
Notes on what makes this Part 11 defensible:
- Who / what / when is captured on every row (§11.10(e)), including the meaning of each signature (Author, Reviewer, Approver) per §11.50.
- Reason for change is required on modifications after initial approval and on any record-affecting override.
- Prior and new content hashes demonstrate integrity (§11.10(c)) so any tampering is detectable.
- Once APPROVE is signed, the record is locked; further changes require a new version and a new signature cycle, not an overwrite.
- The same schema applies to the RMF (
RMF-*risk assessments,SR-*cybersecurity risk items) and to verification and validation records supporting the cybersecurity deliverables.
How this ties into postmarket
Clearance is not the finish line. Section 524B and the QMSR both impose ongoing cybersecurity obligations, and the premarket file is what those obligations run on. Monitoring (vulnerability and KEV feeds, SBOM/VEX upkeep) feeds triage, which feeds coordinated disclosure and CAPA, which updates the same DHF and risk management file that supported the submission. That is why integration matters: a submission built on records the QMS can carry forward is one continuous file, not a fresh start every eighteen months.
Common concerns
"Our QMS does not have a cybersecurity process. Do we need to write one?" Not a parallel one. Cybersecurity activities attach to the procedures already in place: design controls (7.3), risk management (7.1), purchasing (7.4), and CAPA and complaints (8.x). Where a light procedural hook is useful - for example referencing the threat model as a design input or the management plan in the complaint-handling SOP - the change is a cross-reference, not a new quality system.
"Are these records subject to FDA inspection?" Yes. Once filed in the DHF and risk management file, they are inspectable like any design or risk record under the QMSR. That is the point of authoring them as controlled records from day one.
"What happens when we make a design change after clearance?" The same design change control (7.3.9) applies. The threat model, risk assessment, and verification evidence are updated as part of the change, and any submission consequence (letter to file, Special 510(k), or new submission) is a downstream determination the manufacturer makes against its already-updated file.
How Blue Goat approaches this
Blue Goat Cyber authors every premarket cybersecurity deliverable as a controlled record designed to drop into a specific ISO 13485 / QMSR clause - design input, design output, verification record, or risk management file entry - with a stable document ID and editable source. The methodology follows the FDA Secure Product Development Framework and the Feb 3, 2026 final premarket guidance, referencing ISO 14971, ANSI/AAMI SW96, IEC 81001-5-1, and IEC 62304 so the artifacts read in the same language as the rest of the technical file. Our team (CISSP, OSCP, ex-military red team) leads the technical authoring; the sponsor's quality and regulatory team registers, approves, and owns each record. If the FDA raises cybersecurity deficiencies after our submission, we resolve them at no additional cost. See our FDA premarket cybersecurity service for the full deliverable set.
Download the full guide: Integrating Premarket Cybersecurity Deliverables Into Your QMS (PDF) - the deliverable-to-clause table, ownership matrix, and postmarket tie-in.
FAQ
Are FDA premarket cybersecurity deliverables part of the quality management system?
Yes. The Feb 3, 2026 FDA guidance is titled Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions and states that QMSR documentation is "one source of documentation to include as part of the premarket submission." The artifacts are QMS records first and submission attachments second.
Where does the threat model live under ISO 13485?
The threat model is a hazard-identification input to the risk management file under Clause 7.1, integrated with ISO 14971. It is not a standalone document - it feeds the cybersecurity risk assessment and the overall risk management report, and it is updated whenever design changes affect the attack surface.
Does the QMSR replace 21 CFR 820.30 design controls for cybersecurity?
Yes. Effective February 2, 2026, the QMSR incorporates ISO 13485:2016 by reference. The former standalone §820.30 design-controls section is satisfied through ISO 13485 Clause 7.3. Security requirements are design inputs (7.3.3), architecture is a design output (7.3.4), and SAST and penetration testing are design verification (7.3.6).
Do I need a separate cybersecurity SOP?
Usually no. Cybersecurity activities attach to existing procedures: design controls, risk management, purchasing, and CAPA. A light cross-reference in the existing SOPs - naming the threat model as a design input, or the cybersecurity management plan in complaint handling - is typically sufficient.
How do the same records support Section 524B postmarket obligations?
The premarket file becomes the postmarket file. Vulnerability monitoring, SBOM/VEX upkeep, and coordinated disclosure feed the complaint handling (8.2.2) and CAPA (8.5) processes, which update the same DHF and risk management file that supported the submission. That continuity is what makes 524B compliance operationally sustainable.
Related reading
- FDA Section 524B Subsections Explained
- Types of 510(k): Traditional, Special, and Abbreviated Explained
- Did AAMI SW96 Replace TIR57 for FDA Submissions?
- The Impact of 524B(b)(2) on Medical Device Cybersecurity
About the author
Christian Espinosa, CISSP, Founder, Blue Goat Cyber. Christian leads a team focused exclusively on medical device cybersecurity for FDA premarket submissions and postmarket compliance under the QMSR. Read more about Christian.