Total Product Lifecycle Security for Devices

A device does not stop accumulating security risk when it ships. Software components lose support. Credentials need rotation. Update services change. Eventually, a hospital retires the device, and someone must remove its patient data and access credentials.

We approach Total Product Lifecycle (TPLC) security by asking what must remain defensible at each of those transitions. A Secure Product Development Framework (SPDF) turns the answers into engineering work, assigned responsibilities, and evidence. A policy document alone cannot do that.

Why this matters

A cybersecurity failure can expose patient information, interrupt monitoring, or change device behavior. The risk assessment must connect those system effects to possible patient harm. “Loss of availability” is not enough if the real consequence is a clinician missing an alert.

The FDA's February 3, 2026, final guidance, Cybersecurity in Medical Devices, places lifecycle security and an SPDF within the manufacturer's quality-system practices. IEC 81001-5-1 and ANSI/AAMI SW96:2023 also address processes for managing security risks.

For manufacturers, the practical question is whether those processes operate beyond the submission deadline. Who monitors component vulnerabilities? Who decides when a field update is needed? Who supports devices after a supplier ends maintenance? We want those answers before release, while the architecture and support commitments can still change.

Official sources: FDA, Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions (February 2026); HHS HIPAA for Professionals; NIST SP 800-218, Secure Software Development Framework; FDA, Content of Premarket Submissions for Device Software Functions.

Understanding the Total Product Lifecycle (TPLC) and Secure Product Development Framework (SPDF)

TPLC covers concept, design, development, manufacturing, deployment, maintenance, and disposal. It includes the device and the infrastructure needed to build, operate, update, and retire it.

An SPDF supplies the repeatable security practices within that lifecycle. It connects requirements, architecture, implementation, testing, vulnerability handling, and maintenance. It should produce evidence that a manufacturer can use both for regulatory review and for decisions about fielded devices.

Teams sometimes use SPDF and Secure Software Development Lifecycle (SSDLC) interchangeably. Both involve repeated cycles of planning, implementing, reviewing, and testing changes. For a medical device, we also need to account for hardware interfaces, manufacturing provisioning, companion applications, cloud services, and retirement procedures. Software development alone does not cover every trust boundary.

The Importance of Considering the Entire Product Lifecycle

Decommissioning is where assumptions about the operating environment break down. A device may spend its working life in a controlled hospital room, then move to storage, resale, recycling, or disposal. Physical access changes. Data and credentials may remain.

In the FDA letters we reviewed for our September 2026 MTEC webinar, threat-model gaps included decommissioning, supply chain, and end-to-end infrastructure. Cybersecurity labeling findings also included missing end-of-life and decommissioning content. These were findings in our reviewed sample, not an industry-wide prevalence estimate.

We treat retirement as a design requirement. Manufacturers need to identify:

• Where patient data, logs, backups, and credentials persist.
• How authorized personnel erase or destroy those records.
• How the device is disconnected from accounts and supporting services.
• How personnel confirm that the retirement procedure succeeded.

Encryption helps protect stored data, but it does not replace a disposal procedure. The same concern applies to other equipment with persistent storage, including printers: removing equipment from service does not remove its data.

Vulnerabilities in the Update Process

An update mechanism is both a security control and an attack surface. It must deliver fixes without giving an attacker a way to install unauthorized software.

On a Class II wearable we tested, the BLE firmware-update bootloader checked a CRC but did not verify a cryptographic signature. We replayed a captured firmware image with a one-byte modification. The device installed it and rebooted into the modified firmware.

The recommended remediation was signature verification in the bootloader before committing the image, using ECDSA P-256, with the public key stored in a write-protected region. A monotonic version counter would provide anti-rollback protection. Those are distinct controls: an integrity check for accidental corruption does not establish who authorized the firmware.

Transport security still matters. We examine HTTPS/TLS configuration, cipher suites, credentials, and key handling, but an encrypted connection is not proof that the update package is authentic. Nor should a key copied from a public example on Stack Overflow become a production secret.

We also ask how the device behaves if an update fails. A patch path needs authentication, package integrity, rollback resistance, and recovery behavior designed before deployment.

Threat Modeling and the Wider Development Environment

Threat modeling should influence design decisions, not merely describe them after code freeze. We map data flows and trust boundaries first, then identify threats, specify controls, and define the tests that will exercise them.

In our September 17, 2026, secure-by-design workshop in Singapore, we used an illustrative wireless device-to-base-station link to trace this process. The threat was spoofing through unauthenticated pairing. The proposed control was per-device certificate authentication, and the penetration test case checked whether pairing rejected an unauthenticated device. This was a teaching example, not a reported engagement outcome.

That connection between threat, control, and test is the part teams skip. A diagram that names a wireless boundary does not show that anyone tested it.

See also: Legacy Medical Device Cybersecurity Risks in Hospitals, and Medical Device Cybersecurity Lifecycle.

The scope must also extend beyond the device. We examine development access, build systems, signing infrastructure, suppliers, companion applications, and cloud dependencies. Hosting location matters when natural disasters or political instability could interrupt infrastructure or access to data. These dependencies belong in lifecycle planning even when they sit outside the manufacturer's own network.

Challenges in Implementing a Secure Product Development Framework

The hard part of implementing an SPDF is assigning security work to the people and release decisions that already exist. Common obstacles include:

• Lack of Expertise and Resources: Startups and smaller manufacturers may lack the staff or budget to establish an SPDF. They still need named owners for threat modeling, vulnerability assessment, and remediation decisions.
• Prioritizing Speed to Market: Security work deferred until submission can expose architecture problems when changes are most disruptive. We recommend scheduling security reviews alongside design milestones.
• Outsourcing Development: A contractor's promise to follow secure development practices is not evidence. Manufacturers need access to requirements, component inventories, testing results, and unresolved defects.
• Resistance to Change: New reviews and release criteria add work. They are more likely to stick when each has a clear owner, required input, and decision to make.

We do not need an adoption percentage to explain the problem. An SPDF is incomplete when nobody can show how a security finding changes a requirement, blocks a release, or triggers a field action.

Building a Secure Product Development Framework that Works

We recommend building the SPDF around work products and decisions, rather than a separate set of security promises:

• Adhere to Secure Coding Standards: Select applicable practices, such as the CERT Secure Coding Standards, and make them part of engineering review. Record exceptions and their rationale.
• Implement Multi-Layer Verification: Require review and approval before merging code changes. Protect branches and separate permissions so one compromised account cannot silently alter and release software.
• Automate Security Testing: Put static code analysis and software bill of materials (SBOM) checks into the CI/CD pipeline. Define who assesses results and which findings block release. Automated scans do not replace penetration testing.
• Secure the Development Environment: Use multi-factor authentication, secure remote access, and restricted permissions. Include build infrastructure, repositories, and signing keys in the threat model.
• Establish a Secure Update Process: Design authenticated delivery, digitally signed packages, rollback resistance, and recovery behavior. Test the complete update path, including rejected and interrupted updates.
• Plan for Decommissioning and Disposal: Identify sensitive data across every component and document sanitization steps. Put usable retirement instructions in customer-facing labeling.

Keep the SBOM tied to vulnerability monitoring rather than treating it as a submission export. Record component support status and end-of-support information so maintenance decisions reflect what suppliers will actually support.

Finally, connect the evidence. A threat should lead to a control requirement, a security test, a result, and a residual-risk decision. When a control changes, revisit the affected threat and test. This is how the framework stays useful after the first release.

Conclusion: Embracing the Total Product Lifecycle Approach

TPLC security means planning for changes in the device, its dependencies, and its operating environment. An SPDF makes that planning repeatable.

We start with threats that can influence architecture. We test update paths and other exposed interfaces. We connect findings to patient harm, track component vulnerabilities after release, and plan retirement before devices leave the factory.

This takes time and resources, particularly for smaller manufacturers. The alternative is to discover that a fielded device cannot accept a needed patch or cannot be retired without exposing data. Lifecycle planning reduces those avoidable constraints. It does not promise that a device will remain free of vulnerabilities.

How Blue Goat approaches this

We help medical device manufacturers connect threat modeling, security risk management, SPDF practices, SBOM work, and penetration testing across the TPLC. Our scope includes the supporting systems and interfaces that affect the device, not just its firmware.

We test security controls against defined attack paths and document findings, reproduction steps, risk implications, and remediation recommendations. Retesting checks whether a remediation addresses the finding. This is security testing, not a replacement for the manufacturer's verification and validation responsibilities.

For submission support, we help connect security claims to requirements and test evidence. When a manufacturer receives an FDA cybersecurity deficiency letter, we can review the requests and help identify the missing evidence or required security work. We do not promise clearance or a particular review outcome.

Learn more about our TPLC support here: FDA premarket cybersecurity services.

Related reading: What Is MedTech? How It Differs From Medical Devices and Life Sciences.

FAQ

What is Total Product Lifecycle (TPLC) security?

TPLC security means managing cybersecurity from device concept through design, manufacturing, deployment, maintenance, and disposal. It includes the device's supporting systems and continues after the product ships.

How does the SPDF relate to TPLC security?

An SPDF provides repeatable practices for building and maintaining security within the TPLC. We use it to connect threat modeling, requirements, secure implementation, security testing, and vulnerability handling.

Why is secure decommissioning important for medical devices?

Retired devices can retain patient data, logs, and credentials. Without effective sanitization and access revocation, disposal or resale can expose that information, creating privacy breaches and potential regulatory penalties.

Does the FDA require TPLC security for medical devices?

The FDA expects manufacturers to manage cybersecurity across the total product lifecycle. Its February 3, 2026, final guidance describes lifecycle security expectations. Applicable statutory requirements also matter; guidance itself should not be treated as a substitute for determining a device's legal obligations.

What are common challenges in implementing SPDF?

Limited security expertise, release pressure, poor visibility into outsourced development, and resistance to workflow changes can all interfere. We recommend assigning owners and required evidence to each security activity rather than leaving security as a shared but undefined responsibility.

How can manufacturers build an effective SPDF?

Start threat modeling while it can still change the design. Apply secure coding standards, require code reviews, automate suitable security checks, and secure the development environment. Then test exposed interfaces, design secure updates, maintain component monitoring, and document decommissioning procedures.

Continue the Cybersecurity as strategy series

Dive deeper with these companion articles:

• Traditional vs Medical Device Cybersecurity (2026)
• Integrating Cybersecurity Across the Device Lifecycle
• GMP and Medical Device Cybersecurity Compliance
• Cybersecurity as a MedTech Differentiator (2026)
• Market Intelligence & Cybersecurity for MedTech
• 5 Medical Device Cybersecurity Myths, Debunked
• Medical Device Cybersecurity Checklist: Design to Postmarket
• Medical Device Cybersecurity Risk Profiles (2026 Guide)