How a Pacemaker Is Made: Leads, Batteries, Sealing and Firmware

A pacemaker is a small sealed computer that watches the heart's own electrical signals and fires a short pulse when a beat is missing or too slow. It is built from a lithium primary cell, a custom low power circuit, firmware, a laser welded titanium case with ceramic feedthroughs, and one or more insulated, coiled leads, then sterilised and checked for leaks before implant.

This post follows a pacemaker from raw materials to a device talking to a remote monitoring service, one level deeper than our builds of hearing aids and smart rings. Makers keep most production limits private, so where a figure is not published we say so, and example numbers are labelled as examples. Nothing here is medical advice; questions about a specific device belong with the clinic that follows it.

Key takeaways

• A pacemaker senses the heart's intrinsic activity and paces only when needed. Types include single chamber, dual chamber, biventricular (cardiac resynchronisation) and leadless capsules placed inside a ventricle.
• The first fully implanted pacemaker went into a patient in Stockholm on 8 October 1958. Wilson Greatbatch and William Chardack's implantable design was reported in a human in 1960.
• Inside the can: a lithium anode primary cell, a hybrid circuit built around custom integrated circuits, a timing crystal, output capacitors, a magnet sensor and a telemetry antenna, sealed in titanium with ceramic or glass feedthroughs.
• Lithium iodine cells dominated from the early 1970s. Devices that log data and run radio telemetry moved to medium power chemistries such as lithium carbon monofluoride and hybrids.
• Leads use MP35N alloy conductor coils or cables, silicone, polyurethane and fluoropolymer insulation, platinum alloy electrodes and steroid at the tip to keep the pacing threshold low.
• In the US an implantable pacemaker pulse generator is a Class III device that needs premarket approval (21 CFR 870.3610). FDA recognises ISO 14708-1:2014, ISO 14708-2:2019 (cardiac pacemakers) and ISO 11135:2014 (ethylene oxide); software follows IEC 62304.
• Implant radio telemetry in the US uses the 401 to 406 MHz MedRadio band (47 CFR Part 95 Subpart I), where programmers must monitor the channel before starting a session.
• Section 524B of the FD&C Act applies to premarket submissions for "cyber devices" from 29 March 2023 and requires an SBOM, a postmarket vulnerability plan and a way to deliver updates. FDA's premarket cybersecurity guidance was reissued on 3 February 2026.

From raw materials to an implanted pacemaker in one table

Makers do not publish yields, leak rate limits or burn in durations. The table names each stage, what is added, and the typical check. Where firmware and keys enter the device, the table says so.

What does a pacemaker do?

Sensing, pacing and rate response

The National Heart, Lung, and Blood Institute describes a pacemaker as a device that "send[s] electrical pulses to help your heart beat at a normal rate and rhythm." Underneath that sentence sit three jobs.

Sensing. Electrodes pick up the heart's own signals: the P wave from the atria and the R wave from the ventricles. These are millivolts in size and sit on noise from muscles and the outside world. A filtered sense amplifier with a programmable threshold decides whether a deflection is a real beat, and blanking and refractory periods stop the device counting its own pulse or a T wave as a new beat.

Pacing. When the expected beat does not arrive in time, the output stage discharges a capacitor through the lead: a few volts for a fraction of a millisecond. The smallest pulse that reliably captures the muscle is the capture threshold; output is programmed with a margin above it, and some devices track capture automatically to save battery.

Rate response. For someone whose own rate cannot rise with exercise, a sensor estimates activity and raises the pacing rate. Common sensors are an accelerometer and a minute ventilation sensor that reads chest impedance as the lungs fill. A 2017 Heart Rhythm study showed rate adaptive pacing in a leadless pacemaker using "a programmable 3-axis accelerometer," with rate proportional to workload.

Modes use a letter code: chamber paced, chamber sensed, response to sensing, and R if rate response is on. VVI paces and senses the ventricle and inhibits on a sensed beat; DDDR paces and senses both chambers with rate response.

Which types exist?

NHLBI groups pacemakers by how many leads they use and where the device sits.

A device that can also deliver a high voltage shock is an implantable cardioverter defibrillator (ICD), a related product with a bigger capacitor and battery that shares most of the construction.

When were the first implantable pacemakers built?

Oscar Aquilina's history of cardiac pacing, published in Images in Paediatric Cardiology in 2006, sets out the dates.

The first Swedish patient lived with pacemakers for decades; Larsson, Elmqvist and colleagues wrote up "Lessons from the first patient with an implanted pacemaker: 1958 to 2001" in Pacing and Clinical Electrophysiology in 2003. According to Aquilina, the early Stockholm unit used nickel cadmium cells recharged by induction, encapsulated in epoxy resin. The two changes that made modern longevity possible were lithium chemistry and the welded titanium can.

What is inside the can?

A modern pacemaker has four main blocks: the cell, the hybrid circuit, the feedthroughs and the header.

The battery

Mond and Freitag's 2014 review in Pacing and Clinical Electrophysiology traces the chemistry. The first implant used rechargeable nickel cadmium cells, which were quickly replaced by zinc mercury cells that lasted only a couple of years. From the early 1970s the lithium iodine cell became "the dominant power source" for the low voltage, microampere current that single and dual chamber pacing needs.

Lithium iodine is a solid state cell: a lithium anode, an iodine and poly(2 vinylpyridine) cathode, and a lithium iodide electrolyte layer that forms where they touch. As the layer grows, internal resistance rises slowly and predictably, so voltage under load tells you how much life is left.

Its weakness is current. By the early 2000s pacemakers were logging electrograms, running radio telemetry and driving three leads, and Mond and Freitag note that "the current delivery of the lithium-iodine battery was inadequate for these functions." Makers moved to medium rate chemistries: lithium carbon monofluoride (Li/CFx), lithium manganese dioxide, and hybrid cathodes of silver vanadium oxide with carbon monofluoride. Today, the review concludes, all cardiac implantable electronic devices run on lithium anode batteries. Pacemaker cells are primary cells; there is no recharging after implant.

The hybrid circuit

The electronics sit on a small hybrid substrate. The core is one or more custom mixed signal integrated circuits that combine:

• Sense amplifiers and converters for each channel, and the output stage (charge pump, holding capacitor, switches).
• A low power microcontroller running the firmware, with memory for parameters and stored episodes.
• The telemetry transceiver, often with an inductive coil interface for clinic wands.
• An accelerometer for rate response, and a magnet sensor (historically a reed switch) so a clinic magnet can force a fixed rate mode.

A quartz crystal keeps time, and capacitors and protection diodes against defibrillation and electrosurgery complete the board.

Feedthroughs and why titanium

Everything must stay dry for years inside warm salt water. The case is commercially pure titanium, deep drawn into two half shells: biocompatible thanks to its stable oxide, strong when thin, and non magnetic.

A feedthrough gets signals out. In the common design, platinum or platinum iridium pins are brazed through high purity alumina ceramic held in a titanium ferrule that is laser welded into the case; some designs use glass to metal seals. Filter capacitors on the inside shunt radio interference to the case before it reaches the sense amplifiers.

The header

The header is the clear or tinted block on top of the can. It is usually cast epoxy or moulded polymer and contains the connector bores that the lead pins plug into, the set screws or spring contacts that hold them, and, on radio telemetry devices, the antenna, which cannot sit inside a metal box. Standardised connectors let any compliant lead fit any compliant generator; the low profile IS 1 connector for pacing leads and the four pole connector systems for cardiac rhythm devices are defined in ISO standards.

How are leads made?

Conductors

A lead flexes with every heartbeat: at 70 beats per minute that is 70 times 60 times 24 times 365, about 37 million cycles a year. The conductor must survive that without breaking. The classic design is a multifilar coil of MP35N, a nickel cobalt chromium molybdenum alloy, wound as a helix so that bending stress spreads along the wire. Many MP35N wires have a silver core (drawn filled tube) to lower resistance. Newer leads also use thin stranded cables for some conductors, which allow a smaller body. A 2024 review in the Journal of Clinical Medicine describing a lumenless pacing lead lists an MP35N conductor, a polyurethane outer insulator, silicone and ethylene tetrafluoroethylene (ETFE) inner insulators, titanium nitride coated platinum alloy electrodes, and a steroid at the tip.

Insulation

Three insulation families appear, often together:

• Silicone rubber: flexible and stable for decades, but prone to abrasion where leads rub.
• Polyurethane: tougher and slicker, so leads can be thinner; some early formulations cracked. Silicone polyurethane copolymers aim for the best of both.
• Fluoropolymers such as ETFE: thin coatings on individual conductors as a second barrier.

Electrodes and the steroid tip

The tip electrode touches the heart muscle. It is made of platinum iridium or similar alloys and is usually given a porous or high surface area coating such as titanium nitride or iridium oxide, which lowers polarisation and improves sensing. The body reacts to the tip with inflammation and then a fibrous capsule, and that capsule pushes the capture threshold up in the first weeks. A small collar or plug of silicone loaded with a corticosteroid such as dexamethasone sodium phosphate or beclomethasone dipropionate elutes slowly at the tip and damps the reaction, so that thresholds stay low and the device can use less energy.

Fixation

Passive fixation leads have soft tines that catch in the muscular ridges inside the heart. Active fixation leads have a small helix screwed into the muscle, either extendable by turning the connector pin or fixed; the 2024 review describes a 1.8 mm fixed helix on one lumenless lead used for pacing deep in the septum.

How a leadless pacemaker changes the design

A leadless pacemaker removes the lead and the pocket. Everything (cell, circuit, electrodes, sensor and telemetry) goes into a titanium capsule delivered through a catheter from the femoral vein and fixed directly in the right ventricle with nitinol tines or a helix. The pivotal 2016 NEJM study reported that the device "was successfully implanted in 719 of 725 patients (99.2%)", with a 96.0 percent rate of freedom from major complications at six months and no dislodgements.

The trade offs are sharp. The cell is tiny, so every microampere counts; the housing is the return electrode; telemetry must work from inside the heart. In exchange, with no lead and no pocket, lead fracture and pocket problems disappear.

How is a pacemaker assembled and tested?

Cleanroom assembly and the laser welded seal

Final assembly happens in a cleanroom. The cell, the hybrid and any insulating liners and desiccants are placed into one titanium half shell and the feedthrough is welded in. The second half shell is fitted and the seam is laser welded. Welding is often done in a dry inert atmosphere such as argon or a helium and argon mix, so that a small amount of helium is trapped inside, which makes the leak test more sensitive.

Helium leak testing

A hermetic seal is checked with a mass spectrometer leak detector. The device sits in a vacuum chamber and the instrument counts helium atoms escaping from inside. The measured leak rate is converted to how quickly water vapour could get in over the device's life. Makers do not publish their pass limits, which are derived from internal volume, desiccant capacity and target life. A gross leak test, for example bubble testing in a fluid, catches holes too large for the helium test to register because the helium has already gone.

Burn in and final test

Devices are held powered at elevated temperature, then retested, so early failures happen in the factory rather than in a patient. Final test checks sensing, outputs, telemetry, current drain, magnet response and battery voltage, verifies the firmware image, and puts the device into a low drain shipping mode.

Sterilisation

Pacemakers cannot survive steam, so most are sterilised with ethylene oxide gas under a process developed, validated and routinely controlled to ISO 11135, then aerated so residues fall below permitted levels.

Which standards apply?

How long does the battery last, and how is the replacement warning computed?

Longevity

Longevity depends on the cell's capacity and the current the device draws. Pacing current depends on output voltage, pulse width, lead impedance, the percentage of beats that are paced and the pacing rate. Background current covers sensing, timing, memory and telemetry. Device labelling gives projected longevity at stated settings; actual life varies widely with settings and how much the patient is paced.

Worked example 1: energy in one pacing pulse

These numbers are examples, not any model's specification. Treat the pacing pulse as a constant voltage across a resistive lead and tissue load:

• Output: 2.5 V
• Pulse width: 0.4 ms
• Pacing impedance: 500 ohms

Energy per pulse is V squared divided by R, times the pulse width: 2.5 squared is 6.25, divided by 500 is 0.0125 W, times 0.0004 s gives 5 microjoules. At 60 paced beats per minute (1 per second) that is 5 microwatts. Drawn from a cell at about 2.8 V, and ignoring conversion losses, the pacing current is 5 divided by 2.8, about 1.8 microamps.

Double the output to 5.0 V and the energy quadruples, to 20 microjoules per pulse. That is why automatic capture management, which lets the device run closer to the true threshold, is worth so much battery life.

Worked example 2: from current drain to years

Continue the example. Suppose background current for sensing, timing and housekeeping is 6 microamps and the patient is paced 100 percent of the time at the settings above, for a total of about 7.8 microamps. With 1.0 ampere hour of usable capacity:

• 1.0 Ah divided by 0.0000078 A is about 128,000 hours.
• 128,000 hours divided by 8,766 hours per year is about 14.6 years.

If the same patient needs 5.0 V to capture, pacing current rises to about 7.1 microamps, total to about 13.1 microamps, and life falls to about 8.7 years, before radio sessions and stored electrograms add more. That is why two people with the same model can see very different replacement dates.

The elective replacement indicator

Because a lithium iodine cell's internal resistance rises steadily, its loaded voltage is a reliable fuel gauge. Devices measure battery voltage (and on some models battery impedance) periodically under a known load. When the reading crosses a threshold set by the maker, the device reports the elective replacement indicator (ERI, also called recommended replacement time). The threshold is set so that a defined period of normal function, stated in the labelling, remains to schedule a generator change. Many devices also change behaviour at ERI, for example switching to a simpler mode or a fixed rate when a magnet is applied, so the clinic can recognise it. If the cell keeps falling it reaches end of service (EOS), at which point performance can no longer be assured. Medium rate chemistries such as Li/CFx have a flatter voltage curve for most of their life, so makers combine voltage, impedance and coulomb counting (tracking charge actually used) to estimate the remaining time.

At ERI the generator is replaced; the existing leads are usually tested and reused.

What firmware runs in the device, and how does it communicate?

The firmware

Pacemaker firmware is small, deterministic code on a low power processor, much of the timing work done in dedicated hardware. It implements the timing cycles for each mode, sensing and noise rejection, rate response algorithms, capture management, arrhythmia episode detection and storage, battery measurement, and the telemetry protocol. Parameters (mode, lower rate, outputs, sensitivities) live in non volatile memory and are changed by a clinic programmer. Under IEC 62304, the maker must classify this software by the harm it could cause and apply the corresponding life cycle activities, including management of any third party software of unknown provenance (SOUP) it includes. We cover SOUP in our IEC 62304 explainer.

Three ways to talk to an implant

Inductive telemetry. The oldest link uses a wand placed over the device. A coil in the wand couples magnetically to a coil in the can at a low frequency; the ICD studied by Halperin and colleagues in 2008 talked to its programmer around 175 kHz. Close contact acts as a kind of physical access control, and some radio systems still require an inductive start: CISA's ICSMA-19-080-01 notes that before implant and at clinic follow ups, radio sessions on the affected devices "require initiation by an inductive protocol."

MedRadio. In the US, wireless implant telemetry uses the Medical Device Radiocommunications Service. The FCC's rules in 47 CFR Part 95 Subpart I describe MedRadio as "an ultra-low power radio service for the transmission of non-voice data for the purpose of facilitating diagnostic and/or therapeutic functions involving implanted and body-worn medical devices." The core band for implants is 401 to 406 MHz. Programmer and control transmitters there must run under a monitoring system that checks the channel before a session starts, and the rules cap transmissions without data and limit how long certain transmissions may last per hour (for example 3.6 seconds in total within an hour in some modes). Programmers may not relay data in the 401 to 406 MHz band to anything other than an implant or body worn device, so onward links use other services. Implants may also transmit in response to a "medical implant event," an occurrence that requires data to be sent to protect the person's safety. The range of a few metres is what lets a bedside monitor read a device while the patient sleeps.

Programmers and home monitors

The clinic programmer is a dedicated computer, often a tablet based unit with a wand and a radio module, that interrogates the device, runs threshold tests, changes parameters and prints reports. The home monitor is either a bedside box with a cellular or landline modem or an app on the patient's phone. It wakes the implant on schedule or when the device signals an event, downloads data and forwards it to the maker's remote monitoring service, where the clinic reviews it on a web portal. NHLBI notes simply that the device "can send data to your doctor remotely."

How firmware updates are delivered and authorised

Unlike a phone, an implant firmware update is a clinical decision. The usual route is a programmer session supervised by the clinic, because the device's behaviour during the update matters to the patient. The best known public example is the FDA safety communication of 29 August 2017 on a firmware update for a family of radio frequency enabled pacemakers, issued alongside CISA advisory ICSMA-17-241-01. CISA's advisory recommended that healthcare providers discuss the update with patients and "carefully consider the potential risk of a cybersecurity attack along with the risk of performing a firmware update," and said implementation was a matter of the physician's professional judgment.

Authorisation runs at several layers. Programmer software, home monitor software and phone apps are updated through their own channels, which is where most of the patchable attack surface lives, and a maker can also fix server side services without touching any patient's device. FDA's 2026 premarket guidance lists authenticity, which includes integrity, among the security objectives and says devices should verify the authenticity of data and software they receive.

What do Section 524B and FDA guidance require from makers?

The statute

Section 3305 of the Consolidated Appropriations Act, 2023, enacted on 29 December 2022, added section 524B to the Federal Food, Drug, and Cosmetic Act (21 U.S.C. 360n-2), effective 90 days later. FDA's cybersecurity FAQ defines the scope: a "cyber device" (1) includes software validated, installed or authorised by the sponsor, (2) can connect to the internet, and (3) has technological characteristics that could be vulnerable to cybersecurity threats. The requirements do not apply to submissions made before 29 March 2023, but a later change to an authorised device that needs premarket review brings the new submission under the law. Makers unsure whether a device is a cyber device can ask FDA.

A maker submitting a premarket application for a cyber device must:

1. Submit "a plan to monitor, identify, and address, as appropriate, in a reasonable time, postmarket cybersecurity vulnerabilities and exploits, including coordinated vulnerability disclosure and related procedures."
2. Design, develop and maintain processes that give reasonable assurance the device and related systems are cybersecure, and make postmarket updates and patches available.
3. Provide "a software bill of materials, including commercial, open-source, and off-the-shelf software components."
4. Comply with other requirements FDA sets by regulation.

FDA's premarket cybersecurity guidance

FDA's guidance "Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions" was reissued on 3 February 2026 and supersedes the version issued on 27 June 2025. It sets out what FDA recommends a submission contain, including threat modelling, security risk management, security architecture, testing evidence and labelling. For each software component it asks for the level of support the supplier provides and the component's end of support date, and it addresses section 524B for cyber devices. Our premarket guidance walkthrough and threat modelling post go deeper.

Public advisories that shaped these expectations

These dated public records are examples of the categories regulators now design for. They are summarised at the level of mechanism and fix only.

The common thread: the weak points were mostly radio protocols and off body systems, not the pacing algorithm.

Component table: material, why, failure mode

Common misconceptions

"Anyone with a pacemaker can never have an MRI." Not true for many current systems. FDA's guidance on testing and labelling devices for the MR environment (issued 10 October 2023, first issued 20 May 2021) uses the terms MR Safe, MR Conditional and MR Unsafe. A system labelled MR Conditional can be scanned only under the conditions in its labelling, which usually cover the whole combination of generator and leads. Whether a given patient can be scanned is for the clinic and radiology team.

"Anyone nearby can reprogram it." Programming needs a compatible programmer and a session within range. Advisories showed that older protocols lacked strong authentication, which is why makers shipped updates and why FDA now asks for authentication and update plans in submissions. Patients should not change therapy because of a news story; that is a conversation for their clinic.

"A home monitor is just another IoT box." It is part of a regulated system, and CISA's advisories show its credentials, update service and network link carry real risk. Its software deserves the same update discipline as the implant.

"The firmware is proprietary, so there is no supply chain." The pacing core is usually written in house, but programmers, monitors, phone apps and cloud services pull in operating systems, radio stacks, TLS libraries and web frameworks. That is why section 524B asks for an SBOM covering commercial, open source and off the shelf components.

"A dead battery means the heart stops." Devices warn ahead of time through ERI, and clinics follow it through remote monitoring and checkups. Replacement is planned surgery.

Step by step: an SBOM and update record for a pacemaker system

This walkthrough is for engineering teams that build software for implant systems (programmer software, monitor firmware, phone apps and cloud services) and for hospital biomedical engineering teams that keep the inventory. Nothing here touches a patient's device.

1. Map the system you actually ship

List every software item, not just the implant: implant firmware, clinic programmer software, its radio module, bedside monitor firmware, the patient phone app and the remote monitoring service.

2. Generate an SBOM for each firmware build

If the monitor runs an embedded Linux built with the Yocto Project, recent releases inherit the create-spdx class by default through INHERIT_DISTRO, and the image SBOM lands as IMAGE-MACHINE.spdx.json under tmp/deploy/images/MACHINE/. On an older release, add the class yourself:

# conf/local.conf (only if your release does not already inherit it)
INHERIT += "create-spdx"
bitbake core-image-minimal
ls tmp/deploy/images/*/*.spdx.json

If a small device runs the Zephyr RTOS, Zephyr's west spdx command emits SPDX documents (SPDX 2.3 tag value by default) for the build. The --init step creates the CMake query in the build directory before the build:

west spdx --init -d build
west build -d build -b <board> app/
west spdx -d build

For the phone app and the cloud service, generate a CycloneDX SBOM in CI with the OWASP CycloneDX project's cdxgen:

npm install -g @cdxgen/cdxgen --ignore-scripts
cdxgen -o bom.json .

3. Scan each SBOM and keep the result with the release

safeguard scan --sbom tmp/deploy/images/mymachine/core-image-minimal-mymachine.spdx.json
safeguard scan --sbom bom.json
safeguard scan --image registry.example.com/remote-monitoring:1.4.2
ls ./output

Store the SBOM and the scan output next to the signed release artefact. When an advisory lands for a radio stack or a TLS library, you can answer "which builds carry it?" in minutes.

4. Record support level and end of support dates

FDA's guidance asks for both for each component, so make them SBOM fields rather than a spreadsheet one person maintains.

5. Keep the update path auditable, and know how to report

Sign every image, verify signatures on the target, and log which programmers and monitors run which version. Hospital teams should check those versions against maker updates and CISA ICS medical advisories. To report a weakness, see our guide on reporting a medical device cybersecurity problem.

Common mistakes

• Treating the implant as the whole system. Most published weaknesses sat in programmers, monitors, protocols and services. Inventory and SBOMs must cover all of them.
• One SBOM for the product line. Each firmware and app build needs its own SBOM, tied to the exact signed artefact.
• Ignoring end of support dates. An embedded Linux kernel or radio stack that is out of support cannot receive fixes, and FDA asks for those dates.
• Assuming the radio band is a security boundary. MedRadio rules govern spectrum and power, not authentication.
• Pushing implant firmware like a phone update. Implant updates are clinical procedures with backup modes and supervision.
• Weak crypto in the off body systems. Hardcoded keys and home grown protocols recur in advisories; see our post on cryptography mistakes medical device makers should avoid.

FAQ

How is a pacemaker made?

A lithium cell and custom circuit go into two titanium half shells in a cleanroom, connect through ceramic feedthroughs and are laser welded shut. A header with connectors and antenna is added; the device is leak tested, burned in, tested, packaged and sterilised with ethylene oxide.

What battery does a pacemaker use?

A lithium anode primary cell. Lithium iodine was the standard from the early 1970s; devices with more telemetry and data logging use medium rate chemistries such as lithium carbon monofluoride or hybrid silver vanadium oxide and carbon monofluoride cells.

How long does a pacemaker battery last?

It depends on the cell, the settings and how often the device paces; the labelling states projected longevity at given settings. The device warns ahead of time through the elective replacement indicator.

What are pacemaker leads made of?

Fatigue resistant MP35N alloy conductors insulated with silicone, polyurethane or copolymers and fluoropolymer coatings, with platinum alloy electrodes and a steroid eluting collar at the tip.

What is a leadless pacemaker?

A self contained capsule, about the size of a large pill, that is delivered through a vein and fixed inside the right ventricle. It has no lead and no chest pocket.

How does a pacemaker send data to the doctor?

A bedside monitor or phone app reads the device by radio and forwards the data to a remote monitoring service the clinic reviews.

Can a pacemaker be hacked?

Researchers and CISA advisories have documented weaknesses in older telemetry protocols and home monitors, and makers addressed them through firmware, monitor and server updates. Section 524B now requires SBOMs, vulnerability plans and update capability for new cyber device submissions. Patients should follow their clinic's advice.

Can you have an MRI with a pacemaker?

Many current systems are labelled MR Conditional and can be scanned under specific conditions. Whether a given patient can be scanned is a decision for the clinic and radiology team.

What standards apply to pacemakers?

ISO 14708-1:2014 and ISO 14708-2:2019, ISO 11135:2014 for ethylene oxide, ISO 5841-3 and ISO 27186 for connectors, ISO 10993, ISO 14971 and IEC 62304, plus the Class III PMA pathway and section 524B.

Where Safeguard fits, honestly

Safeguard does not design, test or analyse pacemakers, cells, leads or hardware, and it does not scan firmware binaries. Its fit is indirect: the SBOMs section 524B asks for, the open source components in programmer software, monitor images, phone apps and cloud services, and moving those components to fixed versions.

The off body software around a pacemaker is built like any other modern product, from operating systems, radio stacks and open source libraries that need updates throughout a long device life. These fixes are the part a device maker controls, so closing the gap between an upstream fix and a shipped release still matters here.

Fix it without waiting for upstream

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation covers eight categories, including dependencies, licenses, security posture and findings. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.

3. Gold Registry: start from components that are already fixed

registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. This fork and patch flow is in early access today, so ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

The first demo is a real Safeguard CLI session: asked to fix a lodash CVE, the assistant reads the finding and advisory, asks before any command that changes something, edits package.json to lodash 4.17.21, runs npm install and npm test with approval, and pushes nothing. The same flow fits a patient phone app or a remote monitoring service in a pacemaker system.

Click through it at your own pace, or open it full screen.

The second demo sets up the Safeguard runner on your own machine, approves it with its device code and scans from the terminal. That suits a firmware team scanning the SPDX documents its Yocto or Zephyr build emits on the host where the build runs.

Click through it at your own pace, or open it full screen.

The third demo connects Claude to the Safeguard MCP server with OAuth and chooses which tools Claude can use, so a device team can ask which projects carry a component named in a radio stack or TLS library advisory.

Click through it at your own pace, or open it full screen.

To try it on your own repositories, download Safeguard and follow the CLI documentation.

Quick check

Sources

• NHLBI, What Are Pacemakers?
• NHLBI, How Pacemakers Work
• Aquilina O, A brief history of cardiac pacing, Images in Paediatric Cardiology, 2006 (PMC3232561)
• Larsson B, Elmqvist H and others, Lessons from the first patient with an implanted pacemaker: 1958 to 2001, PACE 2003 (PubMed 12685152)
• Mond HG, Freitag G, The cardiac implantable electronic device power source: evolution and revolution, PACE 2014 (PubMed 25387600)
• Reynolds D and others, A Leadless Intracardiac Transcatheter Pacing System, NEJM 2016 (PubMed 26551877)
• Lloyd M, Reynolds D and others, Rate adaptive pacing in an intracardiac pacemaker, Heart Rhythm 2017 (PubMed 27871854)
• Lumenless and Stylet-Driven Leads for Left Bundle Branch Area Pacing: Materials, Techniques, Benefits, and Trade-Offs, J Clin Med 2024 (PMC11355410)
• Halperin D and others, Pacemakers and Implantable Cardiac Defibrillators: Software Radio Attacks and Zero-Power Defenses, IEEE S&P 2008
• Cornell LII, 21 U.S.C. 360n-2 Ensuring cybersecurity of devices (section 524B)
• FDA, Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions
• FDA, Cybersecurity in Medical Devices Frequently Asked Questions
• FDA, Testing and Labeling Medical Devices for Safety in the Magnetic Resonance (MR) Environment
• eCFR, 21 CFR 870.3610 Implantable pacemaker pulse generator
• eCFR, 21 CFR 870.3680 Cardiovascular permanent or temporary pacemaker electrode
• eCFR, 47 CFR Part 95 Subpart I, Medical Device Radiocommunication Service
• FCC, Medical Device Radiocommunications Service (MedRadio)
• CISA, ICSMA-17-241-01
• CISA, ICSMA-18-219-01
• CISA, ICSMA-19-080-01
• CISA, ICSMA-20-170-05
• IEC 62304:2006, Medical device software, software life cycle processes
• FDA Recognized Consensus Standards database (ISO 14708-1, ISO 14708-2, ISO 11135, ISO 5841-3, ISO 27186)
• Zephyr Project, west spdx documentation
• Yocto Project, Creating a Software Bill of Materials
• OWASP CycloneDX, cdxgen

Last reviewed: 25 October 2026.