FDA Cryptographic Testing for Medical Devices

If you submit a cyber device to FDA, crypto is not enough by itself - you need proof that it works in the finished device.

I’d boil the article down to this: after March 29, 2023, FDA expects premarket submissions for cyber devices to include clear cybersecurity records, and crypto sits near the center of taking the risk out of healthcare reviews. I need to show what crypto I use, why I chose it, how keys are handled, how failure cases were tested, and how each result links back to a security requirement and risk.

Here’s the short version:

• FDA looks at both design and testing. Naming TLS, AES, or a FIPS module does not prove the device is safe.
• FIPS 140-3 validates a crypto module, not the full device. I still need device-level test records for secure boot, encrypted traffic, authentication, updates, and key lifecycle.
• FDA expects current crypto choices. The article flags older options like TLS 1.0/1.1, MD5, SHA-1 signatures, Triple-DES, and RSA-1024 as items to avoid.
• Testing must cover success and failure cases. That includes expired certificates, bad signatures, downgrade attempts, dropped connections, rollback attempts, and tampered firmware.
• Traceability matters. Each crypto requirement should map to a test case, actual result, version, test setup, and risk decision.
• Common weak spots are usually proof gaps, not just code gaps. Hard-coded keys, weak storage, third-party library blind spots, missing audit logs, and poor change control can slow review.

A quick way to think about it:

So if I were preparing a submission today, on August 29, 2026, my focus would be simple: use current crypto, test it inside the actual device, document failures as well as passes, and make the record easy for FDA to review.

FDA and NIST Expectations for Cryptographic Controls

FDA and NIST turn the design-versus-validation split into direct cryptographic expectations. FDA's final premarket cybersecurity guidance, issued June 27, 2025, treats cryptography as a core regulatory requirement.^[6][4] Manufacturers need to show that cryptographic controls were picked carefully, built into the device correctly, and tested in the finished product.

Core Cryptographic Controls FDA Expects Manufacturers to Implement

FDA expects manufacturers to use industry-standard cryptographic algorithms and protocols and back them up with solid key management.^[1] That means managing the full key lifecycle: generation, distribution, storage, rotation, revocation, and anti-reuse protection.^[1] It also means using device-unique keys, keeping secrets in protected hardware or secure storage, and staying away from shared master keys.^[16]

FDA also expects robust nonces, along with version and parameter negotiation, so secure settings can remain in place throughout the device's service life.^[1]

Algorithm choice matters too. Manufacturers should choose algorithms and key lengths that will hold up for the full service life of the device and follow NIST SP 800-131A for transitions.^[1][2] FDA flags several deprecated options to avoid, including Triple-DES, SHA-1 signatures, RSA-1024, MD5, and TLS 1.0/1.1.^[17] If a restricted legacy-use algorithm is still needed, that issue should be brought up in a pre-submission meeting.^[1][2]

When FIPS 140-3 Applies and What It Does Not Prove

Even then, module validation is only one piece of the job. Use FIPS 140-3 when the submission relies on a validated cryptographic module.^[1] FIPS 140-3 is a module-level standard run through NIST's Cryptographic Module Validation Program (CMVP), with testing handled by independent accredited labs.^[18][19]

A FIPS 140-3 certificate confirms that a specific module meets defined requirements in areas such as interfaces, key management, self-tests, and lifecycle assurance.^[13] But here's the catch: it does not prove that the medical device around that module is secure.^[13]

CMVP checks the module only. Supplier reliability and fit for the broader operating environment sit outside that scope.^[13]

So while a validated module helps support the compliance case, manufacturers still need device-specific proof that the module was integrated the right way and works securely in the product.^[14][15] That proof should document the exact module version, the device operating environment, and the integration details that keep the validation claim intact.^[14][15] For new designs, manufacturers should point to FIPS 140-3-validated modules, since FIPS 140-2 certificates move to historical status in September 2026.^[19]

That split sets up the next section: module testing versus device-level testing.

sbb-itb-535baee

How Cryptographic Module Testing Differs from Device-Level Testing

A validated module is the starting point, not the finish line. FDA still wants proof that the medical device itself uses that module the right way in the submission record. Put simply: FIPS 140-3 validates the module; FDA testing validates the device. A module can be approved on its own, but the full device still needs proof that it works safely and securely in actual use.

How CMVP and Accredited Lab Testing Work

When a vendor wants a module validated, they work with an NVLAP-accredited Cryptographic and Security Testing (CST) laboratory. That lab uses test methods from ISO/IEC 24759, along with NIST SP 800-140 Derived Test Requirements (DTRs), to check the module against ISO/IEC 19790 and FIPS 140-3.

This testing looks at things like:

• algorithm implementation
• role enforcement
• key generation and zeroization
• self-tests
• physical security features for hardware modules
• interface controls

The lab then sends its test package to CMVP, which is run jointly by NIST and the Canadian Centre for Cyber Security. CMVP reviews the package and, if all goes well, lists the validated module in a public database. In your submission records, include the certificate number and module version. Since FIPS 140-3 validation can take many months, it's smart to engage a CST lab early.

That certificate helps support the submission, but it does not replace device-level verification.

What Must Still Be Tested Inside the Medical Device

CMVP validation does not test how the module behaves once it's inside the device. FDA wants evidence that the validated module still works as intended after integration.

Document each result in verification reports, then trace it to the matching cybersecurity requirement in the design history file. Those results become part of the test record FDA expects in the submission.

What Cryptographic Test Evidence to Include in an FDA Submission

FDA does not treat encryption by itself as proof of compliance. Reviewers want evidence that each cryptographic control was implemented the right way, works in the finished device, and maps back to a security requirement or a known threat.^[1][11] In practice, they look for two things: core cryptographic testing and the records that support it.

The next step is showing how that evidence turns into traceable test proof.

Evidence That Proves Cryptographic Controls Work as Intended

Include the algorithm and protocol rationale, key management architecture, certificate and trust-chain handling, implementation verification results, and pass/fail criteria.^[1][11][12] You should also list the CMVP certificate number and module version as support. But the CMVP reference is supporting evidence only.^[22][21]

For each area, show both expected-case and failure-case results. Expected-case testing shows that valid certificates authenticate as intended or that TLS 1.2+ with approved cipher suites negotiates the way it should. Failure-case testing shows what happens when things break: expired keys, signature failures, downgrade attempts, or tampered firmware. FDA reviewers expect both, not just the happy path.

Vulnerability testing for cryptographic implementations should focus on the interfaces where crypto functions meet untrusted input. That usually means:

• Network interfaces
• Firmware update mechanisms
• Remote management portals

Use targeted fuzzing, misuse-case testing, and third-party library scans tied to SBOM entries. Independent penetration testing adds one more check by simulating attacker behavior in a live setting. That matters a lot when your claims involve authentication or encrypted communications.^[1][11][7]

Traceability from Security Requirements to Test Results

Traceability is what turns a design decision into device-specific proof. The simplest way to show that is with a security requirements traceability matrix focused on cryptographic controls.^[1][3][12]

For each requirement, record the source requirement, verification method, expected outcome, actual result, device and library version, test environment, and risk disposition.^[1][11][12] If there was a fix or a compensating control, put it directly in the matrix. Don’t make the reviewer piece it together from scattered files.

Cross-references to the threat model, test reports, and design documentation help remove confusion.^[3][12] That record is what reviewers use to check your cryptographic claims without coming back with extra questions.

Supporting Submission Artifacts That Reinforce the Cryptographic Record

Include the SBOM and lifecycle documentation for cryptographic libraries, HSM firmware, and other dependencies.^[8][5] Under Section 524B, FDA requires an SBOM for cyber devices in premarket submissions. Those entries tie your vulnerability testing to the exact software and firmware in the device and support your vulnerability management process.^[8][5][9]

These records also make weak spots in the submission easier to spot.

Common Compliance Gaps and a Submission Readiness Checklist

Frequent Issues That Delay Review or Weaken Assurance

Once the test record is assembled, the main review risk usually isn’t weak cryptography. It’s weak proof. A lot of submissions run into trouble because the evidence is thin, incomplete, or hard to trace. FDA reviewers tend to flag the same patterns again and again.

One of the biggest trouble spots is key management. Hard-coded keys, keys derived only from device identifiers, or keys stored in plain text on the device or in a companion app can weaken assurance, even if the algorithm itself is sound ^[7][2]. Be clear about where keys are stored, who can get to them, and how the device prevents reuse or export.

Another common issue is unsupported or legacy algorithms. Stick to algorithms and modes that fit the documented threat model and align with current NIST guidance ^[7][9]. A sound submission doesn’t just say what was used. It also explains why that choice fits the system.

Third-party component gaps also show up a lot. For every third-party crypto dependency, include the exact component version, build, and device-specific test results. Reviewers want configuration details and test data that show how the component works inside the actual device system. A reference to an outside validation certificate, by itself, usually isn’t enough.

Two more gaps often slow review: untested fallback or error modes and missing authentication event logs. For example, what happens when a certificate expires? What happens if the network connection drops in the middle of a security flow? FDA expects logs for enrollment, login failures, lockouts, key changes, certificate errors, and secure update attempts as part of auditable security events ^[9][10]. Module validation should be treated as supporting evidence, not the whole case.

The last major weak spot is change control after the original design is finished. Library updates that weren’t reviewed, configuration changes that shift cryptographic behavior, or firmware and cloud changes that alter security flows can all turn a once-acceptable submission into an incomplete one. Track every crypto-related change with documented impact analysis and approval ^[10][22].

These are the weak points worth checking before anything goes out the door.

A Checklist for Submission Readiness

Before submission, check the package against the items below.

• Confirm crypto design alignment. Verify that all algorithms, key lengths, and protocols match FDA and NIST expectations. Also document the reason for each choice, tied back to the threat model.
• Determine whether FIPS 140-3 applies. Confirm that the certificate is current and that the exact module version matches the validated scope ^[23][20].
• Test in the full device context. Run end-to-end tests for encryption, authentication, certificate handling, secure update flows, and failure conditions across firmware, software, cloud services, and connected apps or accessories.
• Assemble traceable evidence. Build a security requirements traceability matrix that links each cryptographic requirement to a test case, an actual result, and a risk disposition. Include component versions, validation status, and SBOM entries.
• Document residual risk decisions. Record each finding, compensating control, and residual-risk rationale in one place so a reviewer can follow the logic without needing follow-up questions.
• Verify change control is in place. Confirm that version control, regression testing, and impact analysis workflows cover the full crypto stack before and after submission.

FAQs

Does FIPS 140-3 validation cover my whole device?

No. FIPS 140-3 validation applies to the cryptographic modules or HSMs used inside a medical device, not the entire device.

The FDA looks for much more than that. It expects testing across the full device ecosystem, including firmware, software, mobile apps, and communication interfaces. That usually includes penetration testing, vulnerability assessments, and fuzz testing too.

What crypto failures should I test before submission?

Test beyond basic functionality in every operating scenario the device might face. Check key management from end to end, including provisioning, renewal, and revocation. Then push cryptographic functions under stress to make sure any failure won't affect patient safety or open the door to unauthorized access.

Go a step further and simulate field conditions, too. That means testing what happens during power loss in the middle of encryption, as well as during unstable network connections. You also want to confirm that secure boot stops tampering and that hardware protections can't be bypassed through side-channel attacks or physical manipulation.

What documents should I include for FDA crypto review?

Include proof that encryption is built into the device’s design and carried through its full lifecycle. That means providing a cybersecurity management plan, threat modeling, risk assessments, algorithm documentation, and a key management plan.

You should also submit:

• FIPS 140-3 validation certificates
• Documentation covering secure communication
• Documentation for data at rest protection
• Documentation showing how firmware updates are protected
• A traceability matrix that links cryptographic controls to threats and test results

This package should show a clear line from design choices to risk handling and verification. In plain terms, it should be easy to see what control was used, which threat it addresses, and how testing confirmed it works.

Related Blog Posts

• Cybersecurity Testing for 510(k) Submissions: Guide
• FDA Cybersecurity Design Controls: Key Requirements
• FDA Encryption Standards for Medical Devices
• Testing Medical Device Interoperability