Total Product Life Cycle (TPLC) Cyber Timing Guide

Free Guide · Blue Goat Cyber · Updated 2026

GUIDE · TOTAL PRODUCT LIFE CYCLE

The TPLC Cybersecurity Timing Guide Why FDA's Total Product Life Cycle framework makes 'later' the most expensive answer in medical-device development.

250+ 0 6–10 wk FDA submissions supported Cybersecurity rejections Class II eSTAR cyber pack SINCE 2014 TRACK RECORD TYPICAL TIMELINE

WHAT YOU'LL GET FROM THIS RESOURCE

Section 524B and the Feb 3, 2026 final guidance treat cybersecurity as a continuous obligation, not a pre-submission task. This guide maps the artifacts FDA expects at each phase of TPLC and shows the cost-of-delay math for getting them in early.

The myth of 'later' Cybersecurity in a medical device is not a gate you walk through once. It is a continuous obligation that begins at concept and ends when the last unit is decommissioned. The FDA codified this in its Feb 3, 2026 final guidance, Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions, and reinforced it through Section 524B of the FD&C Act.

• Cybersecurity is treated as a quality-system requirement, not an add-on.
• Every artifact (threat model, SBOM, pen test, SPDF) has a defined home in the timeline.
• Remediating findings post-submission costs roughly 5–10× building them in.

What TPLC actually requires

The Total Product Life Cycle approach maps cybersecurity activity to four phases. Skipping or compressing any phase puts both your submission and your patients at risk.

1. Design & development Threat modeling (typically STRIDE), secure architecture review, secure coding standards, and SBOM generation begin here. These artifacts are the foundation for every downstream deliverable.

2. Verification & validation Penetration testing, vulnerability scanning, and fuzz testing must be performed by an independent party. The FDA explicitly looks for evidence that testing was not performed by the original developers.

3. Premarket submission The Secure Product Development Framework documentation, cybersecurity risk assessment, and labeling content are bundled into your 510(k), De Novo, or PMA. Missing them triggers Refusal-to-Accept.

4. Post-market Vulnerability monitoring, coordinated disclosure, and patch deployment continue for the life of the device. The FDA expects ongoing evidence of these processes, not a one-time certification.

The cost-of-delay math

Building cybersecurity artifacts during early-phase development is a small fraction of the cost of remediating gaps after a Refusal-to-Accept. A single FDA Additional Information letter averages 90–180 days of submission delay - a full quarter of runway for an early-stage MedTech, and the only line item on the project plan that can move that far that fast.

When you start Effort to produce the cyber Submission risk artifacts

Design phase Lowest - artifacts emerge as a Lowest - native to the design by-product of the DHF history file

When you start Effort to produce the cyber Submission risk artifacts

Verification phase Moderate - partial rework of Moderate - bridging documentation architecture and risk file needed

After RTA High - reverse-engineer the DHF + High - clock restart, investor optics, restart 510(k) clock runway hit

REVIEWER PERSPECTIVE

FDA reviewers do not penalize a small device for being small. They penalize submissions where cyber artifacts were clearly bolted on after the fact. A right-sized SPDF, a STRIDE threat model, and a third-party pen test traced to your risk file is enough for the vast majority of Class II software-enabled devices.

How to use this guide

Map your current state to each of the four TPLC phases. Where you find a gap, that is where your first conversation with a cybersecurity partner should focus. The goal is not to do everything at once - it is to make sure each artifact is in motion before its corresponding phase ends.

• If you are pre-design, schedule architecture review before the first sprint locks scope.
• If you are mid-development, run a STRIDE pass before V&V begins.
• If you are pre-submission, do an SPDF readiness audit before the eSTAR is built.
• If you have already submitted, set up post-market monitoring and CVD before the first vulnerability lands.

When to use this guide

This guide is most useful in one of the following situations. If none of them describe your team, the resources index has a better fit.

• You are scoping cybersecurity for the first time and want to know what fits in which sprint.
• Your team built the device first and is now trying to bolt cyber on before submission.
• You are mid-development and your QMS does not yet describe cyber activities by TPLC phase.
• Investors or board members are asking why cyber spend can't be deferred until after clearance.

The TPLC phase × artifact matrix Use the matrix below to locate every Section 524B artifact in your own development plan. If a cell is empty in your plan, that is a gap.

TPLC phase Cyber artifacts Owner Independence produced

Concept / design Architecture diagram, System architect + cyber Internal trust-boundary map, initial lead

STRIDE pass

Development SBOM Eng leads Internal (CycloneDX/SPDX), secure-coding evidence, SAST/DAST log

Verification & validation Threat model freeze, pen Cyber lead External required test, fuzz, vuln scan,

SPDF doc

Premarket submission eSTAR cyber package, RA/QA + cyber lead External-signed labelling, CVD plan

Post-market Vuln monitoring, SBOM Cyber lead + PMS owner Mixed refresh, patch validation, CVD intake

Step-by-step playbook

1. Anchor every cyber artifact to a TPLC phase in your QMS. Open your design controls SOP and add a 'cybersecurity activities' column to your phase-gate matrix. Reviewers love a QMS that names cyber explicitly; they distrust one where cyber lives only in a side document.

2. Schedule the first STRIDE pass before architecture freezes. A threat model after architecture freeze is a documentation exercise. A threat model before freeze actually changes the design. The cost difference is one sprint vs. several.

3. Generate the SBOM continuously, not at submission. Wire SBOM generation into CI on every build. The SBOM in your eSTAR must reflect the exact build you are submitting - a static SBOM exported once is almost always stale by the time the reviewer opens it.

4. Book independent testing before V&V starts, not when V&V is over. Independent pen testers need the same architecture and threat model your developers have. Bringing them in early means findings can be remediated in-sprint instead of triggering a V&V re-run.

5. Stand up post-market processes before the first sale. The CVD intake page, the vulnerability triage workflow, and the patch validation pipeline all need to exist on day one of commercial sale. Reviewers ask for evidence these processes are real, not aspirational.

Worked example - a typical Class II MedTech

Setup A 12-person Class II diagnostic startup with a BLE wearable, a phone app, and a cloud backend. They are 4 months from planned 510(k) submission with no formal threat model and an SBOM exported once, two sprints ago.

Walk-through We map their current state to the four TPLC phases. Concept and development cyber artifacts are missing or stale; V&V has no independent pen test booked. We rebuild the threat model against the current architecture, regenerate SBOM in CI, run independent pen testing on firmware + app + cloud, and produce the SPDF doc. Throughout, every cyber control is linked to an existing ISO 14971 hazard so RA/QA does not have to retro-fit traceability.

Outcome Submission goes in on the original date. The eSTAR clears the RTA screen on first review. The team now has a TPLC-phased cyber plan inside the QMS that the next product line can inherit on day one.

Standards crosswalk

The work this guide describes does not live inside any single standard. The crosswalk below shows how each artifact ties to the regulatory text and the consensus standards a reviewer expects you to cite. Use it when you are asked, mid-review, 'where does this come from?'

Artifact	Primary regulatory anchor	Consensus standard
SBOM	Section 524B(b)(3)	NTIA / CycloneDX / SPDX
Threat model	Feb 3 2026 final guidance §V	AAMI TIR57, STRIDE
Cyber risk assessment	Feb 3 2026 final guidance §V	AAMI TIR57 + ISO 14971
Security testing	Feb 3 2026 final guidance §VI	AAMI SW96, IEC 62443-4-1
SPDF documentation	Feb 3 2026 final guidance §IV	IEC 62443-4-1, AAMI SW96
Cybersecurity labelling	Section 524B(b)(2)(A)	Feb 3 2026 final guidance §VII
CVD plan	Section 524B(b)(1)	ISO/IEC 29147 + 30111

HOW TO USE THIS IN A REVIEW MEETING

When a reviewer or an internal stakeholder challenges an artifact, do not defend it on its own merits - point to the row in this crosswalk. Every artifact in your eSTAR cyber package should sit on top of both a statutory anchor and a consensus standard.

Reviewer lens - what FDA actually looks for

Reviewers do not score artifacts on weight or polish. They score them on traceability, independence, and whether the cyber story matches the safety story. The bullets below are what an experienced reviewer scans for first.

• Traceability - every cyber control must trace back to a specific hazard in the ISO 14971 risk file.
• Independence - the engineer who built the system did not also test it.
• Currency - the SBOM and threat model reflect the build that is actually being submitted, not last sprint's.
• Coverage - the threat model addresses every trust boundary shown on the architecture diagram.
• Disclosure - a coordinated vulnerability disclosure (CVD) plan exists, with a published intake path.
• Labelling - end-user cybersecurity content (intended use, controls, residual risks) is in the IFU.

What 'evidence-grade' looks like

Reviewers are not impressed by length. They are impressed by traceability. The four characteristics below are what separates an evidence-grade cyber package from one that draws an Additional Information letter.

1. Versioned Every artifact carries a version, a date, and a commit/build identifier. The SBOM in your eSTAR matches the build under review, not last sprint's.

2. Linked Threat-model entries link to risk-file hazards. Pen-test findings link to threat-model entries. Mitigations link to design controls. The reviewer can walk any chain end-to-end without leaving the package.

3. Independent Testing was performed by an engineer who did not write the code. The org chart in the SPDF documentation makes that visible.

4. Operational Post-market processes (vuln monitoring, CVD intake, patch validation) exist as live processes with named owners - not as procedures that will be 'stood up at launch'.

Pitfalls we see in the wild

• Treating the threat model as a one-time deliverable instead of a living document.

• Generating SBOM only at submission time - never matches the build that actually ships.

• Letting V&V start before independent pen testing is even scheduled.

• Booking pen testing at the end, then having no time to remediate findings.

• QMS that mentions cyber only in a side procedure, not in the phase-gate matrix.

Frequently asked questions

We're already in V&V - is it too late?

No. The most common starting point is mid-V&V. Expect compression: STRIDE pass on the frozen architecture, independent pen test on the V&V build, SBOM regenerated against the V&V baseline, SPDF documented retroactively. The package is honest about the timeline; reviewers care about the artifact quality, not whether you started at concept.

Do we need a threat model if we already did a security risk assessment? Yes. A threat model and a cybersecurity risk assessment are different artifacts under the Feb 3 2026 guidance. The threat model enumerates threats against trust boundaries (typically STRIDE). The risk assessment scores those threats and links them to ISO 14971 hazards. The eSTAR expects both.

How current does the SBOM have to be? It must reflect the build under review. If your V&V build is dated July 2 and your SBOM is dated June 1, expect an Additional Information letter.

Who has to do the pen test? An independent party who is not the original developer. The Feb 3 2026 guidance is explicit. Internal red teams that report to the same engineering leadership as the developers are not considered independent.

How does this fit Section 524B? Section 524B of the FD&C Act, in force since March 29, 2023, makes cybersecurity content a refusal-to-accept item for any 'cyber device'. The Feb 3, 2026 final guidance, Cybersecurity in Medical Devices, defines what that content looks like in practice: SBOM, threat model, risk assessment, security testing evidence, SPDF documentation, labelling, and a coordinated vulnerability disclosure plan. Everything in this guide is written to land cleanly inside that package.

What if our device isn't a 'cyber device'? The Section 524B test is broad: software + connectivity (even transient, even via a phone) + any exploitable technological characteristic. Most software-enabled Class II devices meet it. Even when they don't, the FDA can still ask for cyber content under its general safety-and-effectiveness authority, and a right-sized threat model is the cheapest insurance you can buy against an Additional Information letter.

Action checklist

Use this checklist to confirm the artifacts and decisions covered in this guide are in place before any premarket conversation.

Cyber activities listed by TPLC phase in the QMS, not in a side document. Architecture diagram with every trust boundary labelled. SBOM generated in CI on every build, exported in CycloneDX or SPDX. STRIDE pass complete, with each threat scored and linked to the risk file. Independent pen test booked before V&V starts. SPDF documentation drafted before the eSTAR is built. CVD intake page live before the first commercial sale. Post-market vulnerability monitoring process documented and assigned.

What to do this week

Before any partner conversation, do three things this week: (1) pull the current architecture diagram and confirm every trust boundary is labelled, (2) export the latest SBOM (CycloneDX or SPDX) for the build you intend to submit, and (3) note the TPLC phase you are in. With those three inputs, a good cyber partner can scope a right-sized engagement in 20 minutes - without them, every conversation re-starts from zero.

NEXT STEP

Book a 20-minute discovery call

We'll map your device, your submission timing, and the artifacts FDA expects, and you'll leave with a one-page plan you can share with your team. No deck, no obligation.

(844) 939-4628 (GOAT) ·

go.bluegoatcyber.com/meetings/blue-goat-cyber/discovery-session Scan the QR code to book instantly →

---

Talk to us

This guide is part of Blue Goat Cyber's MedTech cybersecurity library. To apply it to your device program, book a 30-minute strategy session - no cost, no obligation. Or browse all guides.