Total Product Lifecycle: The Framing That Fixes Most Submissions

Most of the deficiency letters I see start with the same gap: a security program built for the submission, not the device.

The FDA's framing is Total Product Lifecycle (TPLC) for a reason. A medical device is in the field for years. Threats evolve. Third-party components age out. Operating systems go end-of-life. Vulnerabilities get disclosed.

If your cybersecurity work ended the day you filed, your device is already drifting.

What TPLC Actually Means

TPLC is not a section of the submission. It is the operating model that produces every section of the submission, and then keeps producing evidence after the device is on the market. The same engineering discipline runs from concept to decommissioning:

Design. Threat modeling, security requirements, architecture views; all derived from the intended use and the clinical risk, not bolted on once the design is frozen. Security requirements live in the same requirements management system as everything else, traceable to risk and to verification.

Development. Secure coding, third-party component analysis, SBOM generation as a build artifact (not a deliverable you scramble to produce later). The build pipeline emits the SBOM, the static analysis results, and the dependency provenance the same way it emits the binary.

Verification. Penetration testing, vulnerability scanning, and fuzz testing scoped to the threat model, not a checkbox at the end. Every test maps back to a threat. Every uncovered finding maps forward to a mitigation or an accepted risk with a justification a reviewer can follow.

Premarket submission. The story of all of the above, told with the evidence to back it. The submission is not the work; it is the readable artifact of work that already happened.

Postmarket. Coordinated vulnerability disclosure, monitoring, patching, SBOM updates, communication with users. The boring, expensive, durable part; and the part FDA is most consistently sharpening expectations around.

End of support. A plan for what happens when the device is still in clinical use after the company has moved on. Most manufacturers haven't thought about this. Reviewers are starting to.

The Two Shapes A Program Takes

In practice, every program we walk into is one of two shapes.

The first shape is submission-shaped. There is a deadline. There is a scramble. Threat models, SBOMs, and architecture views are produced in the final months, by a small team, working backward from a design that is already locked. The submission goes out, deficiencies come back, and the team patches the document rather than the device. Postmarket happens to whoever has the bandwidth.

The second shape is lifecycle-shaped. The same artifacts exist, but they were generated as a side effect of how the team works week to week. The threat model is in version control alongside the design. The SBOM is regenerated on every build. Architecture views are updated when the architecture changes, not when a regulatory filing is opened. Postmarket monitoring is a real process owned by a real person, not a folder somebody promises to check.

The second shape costs less over the life of the device. It is also the only shape that actually scales to a second product.

What This Looks Like In A Submission

Reviewers can tell which shape your program is in within the first few pages.

A lifecycle-shaped submission reads as one coherent system. The intended use statement, the risk file, the threat model, the architecture view, the SBOM, the verification report, and the postmarket plan all reference the same components, the same boundaries, the same data flows. When the reviewer drills into any one of those documents, the others corroborate it.

A submission-shaped submission contradicts itself. The architecture view shows three trust zones; the threat model only addresses two. The SBOM lists components the architecture view does not depict. The postmarket plan promises monitoring for a service the verification report did not test. Each individual artifact may be defensible. Together they look like a system nobody fully owns.

That contradiction is what produces most of the deficiency letters that follow.

The Cheap Way To Adopt It

You do not need a reorganization to start working this way. You need three habits.

First, put the threat model and the architecture view under version control next to the design, and require an update whenever the design changes. Not at submission time. When the design changes.

First-class artifacts beat documentation drives every time.

Second, make the SBOM a build output, not a deliverable. If a human can edit it, it is already wrong. Wire it into CI, sign it, store it, and treat the latest build's SBOM as the source of truth.

Third, name a single owner for postmarket. Not a committee. One person whose job includes watching CVEs against the SBOM, triaging, and deciding what reaches a patch and what reaches a customer communication. Postmarket dies without a name on it.

The teams that operate this way file fewer times, get cleaner clearances, and have fewer postmarket fires. Not because they're spending more. Because they're spending in the right order.

The lifecycle isn't a documentation exercise. It's the design philosophy that makes everything else possible.