Older devices need a current risk plan
Assess legacy-device risks in the context of software support and clinical use.
Legacy is more than a device's age. Its support status, security limits, and clinical use determine the work that needs to happen next.
Use outlasts support
Older devices can remain clinically useful after software stops receiving security updates.
Clinical use can outlast software support
An older device may still have clinical value after its operating system or software components stop receiving security updates. End of support is not the same as end of use. Manufacturers and healthcare providers need a plan for the risks that remain.
Unknown software risks
Incomplete inventories and uncertain software support make vulnerable dependencies harder to assess.
Unknown components leave risk unmeasured
Incomplete software inventories make it harder to identify vulnerable dependencies. Support status can be difficult to establish, especially when an open-source project has no published end-of-life date or a supplier's support depends on a contract.
Changes may trigger review
Device-specific updates may require FDA resubmission; assess the change before proceeding.
A device change can change the FDA context
Software updates, supplier changes, or new components may require a new FDA submission, depending on the device and the change. Assess the regulatory impact rather than assuming an earlier clearance settles the cybersecurity expectations for every future update.
Risk continues after support
Providers need risk documentation and workable mitigations when devices outlast manufacturer support.
Support ends before responsibility disappears
Healthcare providers may keep devices in service after manufacturer support ends. They need risk documentation, mitigation instructions, and the ability to apply appropriate controls. Retirement also needs a plan for removing sensitive data and credentials.
How Medcrypt helps
Plan risk reduction and evidence around your device's support constraints and planned changes.
Combine Medcrypt's cybersecurity consulting and SBOM tools to plan risk reduction and maintain evidence for devices already in service. Scope the work around your device, its support constraints, and the changes ahead.
Device-specific risk assessment
Prioritize legacy-device threats by patient safety impact, exploitability, and regulatory context.
Medcrypt assesses your security posture and helps prioritize threats by patient safety impact, exploitability, and regulatory context. Use that assessment to plan mitigations for older hardware, unsupported software, and the device's actual operating environment.
FDA submission readiness
Prepare cybersecurity evidence for FDA review when device-specific changes require a submission.
Regulatory change and submission readiness
Work with Medcrypt's experts to assess cybersecurity evidence gaps and prepare for FDA review when a device-specific change requires a submission. Align the threat model, risk assessment, and security documentation with the changes you plan to make.
SBOM support evidence
Reuse component EOL/EOS data across SBOMs while documenting support status and estimates.
SBOM and software support evidence
Medcrypt supports SBOM validation and vulnerability monitoring. Its SBOM tools let teams record component EOL/EOS information once and reuse it across SBOMs. Your team still needs to establish support status, supplier commitments, and the basis for any estimated dates.
Patch and mitigation planning
Plan patches, or evaluate clinically appropriate compensating controls with the healthcare provider.
Vulnerability management and patch planning
Establish processes to monitor vulnerabilities and plan patches or updates with Medcrypt's postmarket experts. Where a device cannot be patched, evaluate compensating controls such as network segmentation and restricted access with the healthcare provider. Those controls must fit the clinical environment.
Support transition planning
Document support windows and equip providers to manage risks before support ends.
Support horizons and transition planning
Bring software support windows, EOL/EOS milestones, and customer communication into your risk-management roadmap. Plan how healthcare providers will receive risk information and mitigation instructions before support ends, rather than treating an end-of-support notice as a complete handoff.
Incident-response preparation
Test incident-response plans with tabletop exercises that account for the installed base.
Medcrypt's tabletop exercises help teams test and refine response plans before an incident. Include the installed base in that planning, with responsibilities for vulnerability disclosure, mitigation communication, and the devices that can no longer receive updates.
Legacy-device questions
An earlier clearance date alone does not determine the answer. Section 524B applies to cyber devices, and certain device modifications may require a new FDA submission. Assess both the device's cyber-device status and the regulatory impact of the proposed change. Older devices still need cybersecurity risk management even when a new submission is not required.
Assess the device's security exposure and clinical use, then evaluate compensating controls with the healthcare provider. Network segmentation, monitoring, and restricted access can help manage risk when a patch is unavailable. These controls do not remove every risk; replacement or retirement planning may still be needed.
Record each component's support status and EOL/EOS information where available, including supplier support commitments. Open-source components may have no published end-of-life date, so document the basis for your assessment rather than inventing a date. Medcrypt's SBOM tools let teams enter component EOL/EOS information once and apply it across SBOMs.
Communicate support timelines early and document the remaining risks and recommended mitigations. A healthcare provider needs instructions, training, and the technical ability to manage those risks if the device remains in use. Plan replacement and secure decommissioning too, including data purging, credential resets, and verification that sensitive information cannot be recovered.