FDA's premarket guidance names specific cryptography mistakes: relying on CRCs for security, deriving keys from serial numbers, storing master keys on devices, using deprecated algorithms, and allowing protocol downgrades. Each one lets compromise of a single device or a passive observer reach many patients.
Do not treat a CRC as a security control
The guidance says CRCs are error detecting codes that protect against environmental factors such as noise or electromagnetic interference. They give no integrity or authentication protection against an intentional, malicious actor. Use cryptographic authentication for data whose tampering could cause patient harm.
It gives high stakes examples: the link between a clinician programmer and an implanted device such as a pacemaker, defibrillator or neurostimulator, or between a continuous glucose monitor and an automated insulin pump. Authenticity of information from the device, such as telemetry, matters most there.
Do not let one device reveal keys for others
The guidance asks for an architecture where full compromise of one device cannot reveal keys for other devices. It lists two avoidances:
- Master keys stored on the device.
- Key derivation based only on device identifiers or other discoverable information.
It adds that serial numbers should not be used as keys or as part of keys. Patients may disclose serial numbers when asking about a device, and recalls publish identifiers for affected products. Public key cryptography is mentioned as a way to meet the goal.
Use current standards
Select industry standard algorithms and protocols with proper key generation, distribution, management and protection, and strong nonce mechanisms. The guidance points to current NIST recommended standards, such as FIPS 140-3, or equivalent strength protection expected to stay strong throughout the service life.
It says not to implement algorithms deprecated or disallowed in applicable standards, citing NIST SP 800-131A. Algorithms with "legacy use" status should be discussed with FDA in a pre-submission meeting.
Service life matters. A device sold today may be in service for many years, so pick algorithms with that horizon in mind.
Block downgrades
Implement protocols that negotiate the most recent secure parameters and versions. Do not allow downgrades or version rollbacks unless absolutely necessary for safety, and log and document the event. Downgrades let attackers exploit older, less protected versions.
Related integrity controls
The same appendix asks for hardware based security where possible, verification of firmware and software authentication tags, disabling test and debug ports such as JTAG and UART before delivery, and tamper evident seals on enclosures and sensitive ports.
If your codebase includes custom crypto helpers, a static scan can flag weak algorithms and hardcoded credentials. See detecting weak cryptographic algorithms in code.
Quick check
Is a serial number acceptable as part of a key?
FDA says no. Serial numbers can be disclosed by patients or during recalls, so they should not be part of key generation.
Does a CRC count as integrity protection?
Only against accidental errors. The guidance says CRCs should not be relied on as security controls because they do not stop a deliberate attacker.
Sources
Last reviewed: 19 October 2026.
