# Medical Device Cybersecurity Compliance & PQC | RankShieldMD > Signed cybersecurity evidence for medical-device manufacturers: postmarket monitoring, SBOMs, post-quantum device identity, and ISO 14971 residual-risk dossiers that support your §524B submission. PHI-free, non-device. > > Source: https://rankshieldmd.com/medical-device-manufacturers/ · RankShieldMD (verifiable AI & post-quantum security for healthcare) For medical-device manufacturers # Evidence for every submission. Identity for every device. **FDA §524B lets the agency refuse a cyber-device submission that can't show cybersecurity.** RankShieldMD turns that requirement into signed artifacts your reviewer can verify: postmarket monitoring records, an SBOM, post-quantum device identity, and residual-risk dossiers for the devices you can't patch. It produces evidence that supports your submission, it never makes your submission, and it is non-device by design. Request early access → What §524B asks §524B evidence Post-quantum identity PHI-free Non-device RankShieldMD ledger · §524B artifacts Postmarket monitoring · (b)(1) signed · 0x5377a9a1… Sealing… Device identity · (b)(2) ML-DSA-65 · 0xa6ee5342… Sealing… SBOM · (b)(3) CycloneDX build-tied · 0xfa65fce3… Sealing… Scroll to descend What it is ## What does RankShieldMD do for a medical-device manufacturer? **RankShieldMD produces the signed, independently-verifiable cybersecurity evidence a medical-device manufacturer needs to support an FDA §524B submission and the postmarket program behind it, postmarket monitoring records, a software bill of materials, post-quantum device identity, and ISO 14971 residual-risk dossiers, without ever handling patient data or becoming a medical device itself.** A cyber-device submission can now be refused for missing cybersecurity information, which turns three abstract obligations, monitor postmarket vulnerabilities, show a secure design, provide an SBOM, into artifacts a manufacturer has to be able to produce and defend. RankShieldMD generates each of those as a cryptographic artifact, seals it to an externally-anchored, post-quantum-signed transparency ledger, and emits a verify recipe so an FDA reviewer, an auditor, or a buyer can confirm it without trusting a vendor dashboard. Two boundaries govern the design, and we hold to both honestly: it produces evidence that supports your submission , it never makes your submission, and it never makes an organization FDA compliant, and it works on device identity and integrity, never on protected health information, so adopting it shrinks your PHI footprint rather than growing it. It puts device-makers **ahead of where regulation is heading**, not past a rule that already exists, the FDA expects crypto-agility and migration planning today, and does not yet mandate post-quantum cryptography. Signed artifacts ## Three duties. Three artifacts. Section 524B names three obligations, and a submission can be refused for missing any of them. RankShieldMD produces each as a signed, externally-anchored, independently checkable artifact, and none of it touches protected health information. 01 ### Postmarket monitoring A plan to monitor, identify, and address postmarket vulnerabilities, produced as a signed decision and integrity feed sealed as events happen. signed feed 02 ### Post-quantum device identity A composite ML-DSA-65 with Ed25519 credential that proves a secure design at runtime and rotates in the field without a recall. ML-DSA-65 · Ed25519 03 ### Software bill of materials An SBOM covering commercial, open-source, and off-the-shelf components, emitted in CycloneDX and SPDX and sealed to a build. CycloneDX · SPDX 04 ### Verify it yourself Each artifact anchors to a post-quantum-signed transparency ledger with a verify recipe a reviewer can recompute. independent check ## What does FDA §524B actually require of a connected device? [Section 524B of the Food, Drug, and Cosmetic Act](https://www.fda.gov/medical-devices/digital-health-center-excellence/cybersecurity-medical-devices-frequently-asked-questions-faqs), added by the 2023 Consolidated Appropriations Act, gives the FDA authority to refuse to accept a premarket submission for a cyber device unless the submission carries adequate cybersecurity information. Three requirements sit at its core. First, a plan to monitor, identify, and address postmarket cybersecurity vulnerabilities and exploits in a reasonable time, which means an ongoing program rather than a one-time attestation. Second, a design that provides a reasonable assurance the device and the systems it connects to are cybersecure, together with the processes and procedures behind that assurance. Third, a [software bill of materials](https://www.cisa.gov/sbom) that covers commercial, open-source, and off-the-shelf software components, so the agency and the field can reason about what actually runs on the device. The FDA finalized its [premarket cybersecurity guidance](https://www.fda.gov/regulatory-information/search-fda-guidance-documents/cybersecurity-medical-devices-quality-management-system-considerations-and-content-premarket) describing how it expects these to be demonstrated, with the operative version dated June 27, 2025. What §524B does not do is hand you a checklist that a tool can silently satisfy. It describes obligations you must be able to evidence, which is why RankShieldMD focuses on producing each obligation as a signed, verifiable artifact rather than claiming to make you compliant. The requirement is real and enforceable at the point of submission; the evidence is what a submission stands or falls on. ## How do you secure a device that can't be recalled? By treating the device's identity as something that can move forward in place, and by containing what you cannot change. The cryptographic answer is in-field rotation. RankShieldMD binds each device a composite credential, a classical Ed25519 signature and a post-quantum [ML-DSA-65](https://csrc.nist.gov/pubs/fips/204/final) signature together, and can rotate its keys to post-quantum over the existing connection when the cryptographic horizon shifts, with no physical recall and no change to clinical function. That matters because a device certified today may serve for ten to twenty years, well inside a realistic quantum window, and peer-reviewed work in [npj Digital Medicine (2025)](https://www.nature.com/articles/s41746-025-02082-3) observes that implants are rarely re-crypto-ed once certified and frequently cannot be recalled at all. When rotation is not possible because the device is simply too old or too constrained, the answer shifts from changing the device to changing what can reach it: a compensating control such as network segmentation that reduces the reachable attack surface and brings residual risk to an acceptable level. In both cases the point is the same. The device keeps doing its clinical job, and the security posture around it is strengthened and documented rather than frozen at the moment of certification. Nothing physical has to be swapped for the cryptography, or the containment, to move forward. ## What about unpatchable and end-of-life devices in the field? These are the hardest devices to defend and the ones a §524B postmarket program has to account for honestly. An unpatchable or end-of-life device may never receive another firmware update, yet it continues to serve patients and sits on a network alongside everything else. Pretending it is secure is not an option, and ripping out an installed base is rarely feasible. RankShieldMD approaches it the way a risk file should: contain, prove, and document. First, contain the device with a compensating control, most often network segmentation that limits which systems can reach it, so that even without a patch the exploitable surface is reduced. Second, prove the containment actually holds with verifiable posture evidence, so the segmentation is a fact you can demonstrate rather than a diagram in a policy binder. Third, document the remaining exposure in a residual-risk dossier that references [ISO 14971](https://www.iso.org/standard/72704.html), the standard for risk management of medical devices, so the decision to keep the device in service is a reasoned, recorded judgment with the residual risk brought to an acceptable level. The result is a defensible position: the device stays useful, the risk is bounded and written down, and a reviewer can see exactly why continued operation is acceptable rather than being asked to take it on faith. ## How does the evidence slot into a QMSR (ISO 13485) record? By being portable, objective, and independently verifiable, so it files as evidence rather than needing to be reconstructed at audit time. Under the [Quality Management System Regulation](https://www.federalregister.gov/documents/2024/02/02/2024-01709/medical-devices-quality-system-regulation-amendments), which harmonizes the FDA's quality system requirements with ISO 13485, a manufacturer has to keep objective evidence that its processes were followed and its risk decisions were justified. Cybersecurity is now part of that record, and the weakest version of it is a set of screenshots and assertions assembled the week before an audit. RankShieldMD is built to produce the stronger version. Every artifact it generates, a signed SBOM in CycloneDX or SPDX, a device-identity credential, a postmarket monitoring record, a residual-risk dossier tied to ISO 14971, is exportable, externally anchored, and carries a verify recipe, so it can be filed directly into a QMSR and ISO 13485 record as objective, tamper-evident evidence. When an auditor or an FDA reviewer asks to see that a specific control was in place for a specific build, the answer is a cryptographic artifact they can recompute, not a story someone reassembles. That is the difference between a quality record that survives scrutiny and one that depends on trust. RankShieldMD produces evidence that supports the record; the quality system remains yours, and so does the overall determination of compliance. References ## Primary sources. The regulatory and standards claims on this page trace to primary sources. Each link opens the authoritative document. - [FDA, Cybersecurity in Medical Devices FAQs (section 524B of the FD&C Act)](https://www.fda.gov/medical-devices/digital-health-center-excellence/cybersecurity-medical-devices-frequently-asked-questions-faqs) - [FDA final guidance, Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions (June 27, 2025)](https://www.fda.gov/regulatory-information/search-fda-guidance-documents/cybersecurity-medical-devices-quality-management-system-considerations-and-content-premarket) - [CISA, Software Bill of Materials (SBOM)](https://www.cisa.gov/sbom) - [NIST FIPS 204, Module-Lattice-Based Digital Signature Standard (ML-DSA)](https://csrc.nist.gov/pubs/fips/204/final) - [ISO 14971:2019, Medical devices: Application of risk management to medical devices](https://www.iso.org/standard/72704.html) - [Federal Register, Medical Devices; Quality System Regulation Amendments (QMSR, incorporating ISO 13485)](https://www.federalregister.gov/documents/2024/02/02/2024-01709/medical-devices-quality-system-regulation-amendments) - [npj Digital Medicine (2025), Quantum cryptography and data protection for medical devices before and after they meet Q-Day](https://www.nature.com/articles/s41746-025-02082-3) Explore the platform ## Where to go next. ### Device & implant identity, rotated in the field Composite ML-DSA-65 with Ed25519 credentials and in-field key rotation, so a device certified today stays defensible for its full service life without a recall. Explore → ### Contain the device you can't patch Compensating-control segmentation, verifiable IoMT posture, and ISO 14971 residual-risk dossiers for unpatchable and end-of-life devices in the field. Explore → ### FDA cybersecurity evidence, end to end The postmarket monitoring, secure-design, and SBOM artifacts a §524B submission relies on, produced as signed evidence that supports your filing. Explore → Honest by design ## What we are careful never to claim. ### It supports your submission RankShieldMD produces evidence that supports your §524B submission. It never makes your submission, never renders an FDA decision, and cannot make an organization FDA compliant. ### The FDA doesn't mandate PQC yet Today the FDA expects crypto-agility and migration planning. RankShieldMD puts you ahead of where regulation is heading, not past a rule that already exists. Quantum-safe, not quantum-proof. ### It's device identity, not PHI RankShieldMD works on device identities, credentials, SBOMs, and posture evidence. It is non-device and PHI-free by construction, and never handles protected health information. Answer engine ## Ask RankShieldMD for device makers. Straight answers about verifiable healthcare AI. Tap a question, or type your own. Jamie Kloncz, founder verified human ✓ Ask me anything about proving your clinical AI. I built RankShieldMD so a small practice can prove its AI, not just be asked to trust it. What does FDA §524B require of a connected medical device? Section 524B of the FD&C Act, added by the 2023 Consolidated Appropriations Act, lets the FDA refuse to accept a premarket submission for a cyber device that lacks adequate cybersecurity information. In practice it requires a plan to monitor, identify, and address postmarket vulnerabilities, a reasonable assurance that the device and connected systems are cybersecure, and a software bill of materials covering commercial, open-source, and off-the-shelf components. RankShieldMD produces evidence that supports those obligations; it does not make your submission or make you compliant. Does RankShieldMD make my submission or make me FDA compliant? No. RankShieldMD produces verifiable evidence that supports your submission and your postmarket obligations. It never files your submission, never renders an FDA decision, and cannot make an organization compliant. Compliance is your overall posture and the FDA's determination. We say produces evidence that supports your submission, never makes your submission or makes you compliant. When did the premarket cybersecurity guidance become operative? The FDA finalized its premarket cybersecurity guidance for medical devices with the operative version dated June 27, 2025, which describes how the agency expects manufacturers to demonstrate a reasonable assurance of cybersecurity under §524B. RankShieldMD is built to produce the identity and integrity artifacts that support the design and postmarket expectations that guidance describes. What form does the SBOM take? Section 524B expects a software bill of materials that covers commercial, open-source, and off-the-shelf software components. RankShieldMD emits SBOM artifacts in the standard CycloneDX and SPDX formats and can seal each one to the transparency ledger so a reviewer can confirm the exact bill of materials tied to a given build. The SBOM is a signed artifact, not a screenshot in a slide deck. Does the FDA mandate post-quantum cryptography? No, and we will not tell you otherwise. Today the FDA expects crypto-agility and migration planning rather than mandating specific post-quantum algorithms. RankShieldMD puts a device ahead of where regulation is heading, not past a rule that already exists. We issue composite ML-DSA-65 with Ed25519 identity and keep it rotatable so a device certified now can migrate forward as standards advance. How does a device get post-quantum identity without a recall? RankShieldMD treats device identity as crypto-agile from the start. Each device carries a composite credential, a classical Ed25519 signature and a post-quantum ML-DSA-65 signature together, and its keys can be rotated to post-quantum over the existing connection with no physical recall and no change to clinical function. Peer-reviewed work in npj Digital Medicine (2025) notes that implants are rarely re-crypto-ed and often cannot be recalled, which is exactly the constraint in-field rotation is built for. Is this quantum-proof? No. It is quantum-safe, not quantum-proof. RankShieldMD hardens device identity against the coming threat using post-quantum algorithms, but no quantum computer capable of breaking today's cryptography exists yet, and no one can honestly call any system unbreakable. We build to the NIST standards so a device stays defensible; we never claim an attack is impossible. How do you secure a device that cannot be recalled? You change what can reach it. When a device cannot be patched, recalled, or taken offline, RankShieldMD supports a compensating control such as network segmentation that brings the residual risk to an acceptable level, and documents that decision in a residual-risk dossier referencing ISO 14971. The device keeps running; the reachable attack surface around it shrinks, and the reasoning is written down as evidence. What about unpatchable and end-of-life devices in the field? They are the hardest case and the one this is built for. A device past end-of-life may never get another firmware update, yet it still serves patients. RankShieldMD helps you contain it with a compensating control, prove the containment holds with verifiable posture evidence, and record the residual risk against ISO 14971 so the decision to keep operating the device is defensible rather than silent. How does the evidence slot into a QMSR or ISO 13485 record? RankShieldMD artifacts are designed to drop into your quality system. Signed SBOMs, device-identity credentials, postmarket monitoring records, and residual-risk dossiers are exportable, externally anchored, and independently verifiable, so they can be filed as objective evidence in a QMSR and ISO 13485 record rather than reconstructed at audit time. The evidence is portable to your quality management system, not locked inside a vendor dashboard. Does RankShieldMD handle patient data? No. RankShieldMD works on device identities, credentials, signed commands, SBOMs, and posture evidence, never on protected health information. It is PHI-free by construction. The device keeps doing its clinical job through its own systems; RankShieldMD only proves identity and integrity, so adopting it shrinks your PHI footprint rather than growing it. Is RankShieldMD a medical device? No. It is security and quality tooling that helps device manufacturers meet their obligations. FDA classification turns on intended use, and RankShieldMD's use is to attest device identity and integrity, never to render, drive, or influence a clinical decision. That non-device boundary is deliberate and it keeps clinical judgment with clinicians. Who is this page for? Product-security, regulatory affairs, and quality leads at medical-device manufacturers, the people who own the cybersecurity content of a premarket submission and the postmarket program behind it. Health systems running fleets of long-lived devices they cannot all replace also use the same platform. It is one verifiable RankShieldMD fabric shared with decision provenance and PHI-free audit, not a bolt-on. Early access ## Turn the cybersecurity requirement into evidence you can hand over. Bring a device or a fleet. We'll show you the §524B artifacts as signed evidence, post-quantum identity you can rotate forward, and residual-risk dossiers for what you can't patch. Evidence that supports your submission, verifiable, PHI-free, non-device. Request early access → Ask a question