Symbiote adds on-device runtime integrity to medical devices, checking selected code, memory, control flow, and processes against device-specific policies. No source code or hardware changes required.
Medical devices may remain in service as operating systems, libraries, and third-party components age. Updating a fielded device is a regulated design change, so even a finished fix is slow to reach devices in clinical use.
Updates and patching remain essential, but long-lived devices also need protection that operates while vulnerability management and update processes continue.
Hardware may remain operational after parts of its software stack become difficult to support.
Firmware changes must clear verification, validation, and a regulatory assessment, plus a new FDA submission when the change is significant.
Network tools and design records cannot, by themselves, show whether selected integrity conditions still hold inside a running device.
Our solutions are broadly applicable across medical device categories.
Firmware holds the drug library, the dose limits, and the motor control loop.
Firmware decides which waveform, alarm, and vital sign a clinician sees.
Firmware governs pressure, volume, and gas mixture in real time.
Firmware controls beam delivery, gantry motion, and dose calculation.
Firmware translates surgeon input into motion.
Constrained hardware, wireless interfaces, and no practical service visit.
If firmware decides what the hardware does, the firmware is the control surface worth defending.
// The Solution
Runtime Integrity
Secure Boot establishes a starting point.
Runtime integrity adds scoped assurance during operation.
Secure boot and authenticated updates help control which software can load. Symbiote adds policy-based integrity checks while the device operates.
Symbiote can monitor selected:
Defense goes into the firmware image itself. The protected image moves through your existing test and signing process, and the device defends itself from that point forward, connected or not.
OFRAK unpacks the firmware, inserts the payloads, and repacks it. No source code changes. The image you sign is the protected image.
Embedded in the real-time operating system, the Linux kernel, or a trusted execution environment. It cannot be unloaded while the device is running. Typically 2 to 3 percent average CPU, from around 16K.
Memory integrity, task-spawn enforcement, control-flow integrity, and custom checks on values such as dose limits and calibration constants. You define the response: block, restore, log, alert, or fail safe.
Attestation streams to your SIEM on connected devices and stays local on air-gapped ones. Postmarket claims arrive with runtime data behind them.
No. OFRAK operates on the release binary. Your build pipeline, toolchain, and signing process stay as they are.
Typically 2 to 3 percent average CPU utilization, scheduled only when the processor has spare cycles, tuned per device, and verified against your own acceptance tests before release.
Yes. It’s delivered as a firmware update with no hardware change, on the device’s next scheduled update.
It contributes runtime evidence from fielded devices to your postmarket picture. It doesn’t replace your risk management process, your software bill of materials, or your patch program.
Generally no. Article 2 excludes products covered by Regulation (EU) 2017/745 and Regulation (EU) 2017/746. Accessories and connected software outside MDR scope can still fall under it, so it is worth confirming product by product.
Learn how Symbiote integrates with your medical device firmware, what it monitors and protects, and how it impacts performance.
Thanks! Your message was sent. We’ll get back to you shortly.
There was a problem submitting the form. Please try again.
