Security you can verify,
not just trust.
Every vendor says they are secure. RankShieldMD hands you the tools to check it yourself. The ownable claim is not "unhackable" — it is "verifiable."
RankShieldMD signs every proof with composite post-quantum signatures (ML-DSA-65 with Ed25519), seals it to an append-only, RFC 6962-style transparency log with signed tree heads, and anchors the log root externally so it is pinned in time. The result is evidence anyone can recompute — without trusting us, and without ever touching patient data.
Verification,
not assertion.
RankShieldMD is designed so no single component is trusted blindly. Requests are signed with RFC 9421 signed HTTP messages, so the platform can prove who sent each call. Evidence is sealed to an append-only transparency log with signed tree heads, and the log root is anchored externally. The whole posture rests on one idea: a control you can check beats a promise you have to believe.
Signed for
the long record.
Healthcare evidence outlives the cryptography that created it. RankShieldMD signs with composite ML-DSA-65 and Ed25519, aligned to NIST FIPS 203/204/205, so a proof made today stays defensible whichever way the math moves. It is quantum-safe, not quantum-proof — and built for crypto-agility so algorithms can rotate as standards advance.
Append-only.
Anchored in time.
The transparency log is an RFC 6962-style Merkle log — the same construction behind certificate transparency. Every entry is chained by hash, so altering history breaks the tree root. The current root is published as a signed tree head and anchored to an external record, so a rewritten or forked log is detectable by anyone who checks.
Check it
yourself.
Every evidence package is recomputable. Your auditors, a regulator, or opposing counsel can recompute the hash chain, confirm the composite post-quantum signature, and check the entry against the anchored root using standard tools — without access to our systems and without trusting RankShieldMD. Alter any field, and verification returns false.
Trust that
survives the question.
Bring your toughest security reviewer. Register a baseline, run evidence through the same path, and verify it with your own tools. Verifiable, standards-first, PHI-free by construction.
Security you can verify, not just trust.
RankShieldMD's security posture is built on a single, honest premise: the evidence it produces is independently verifiable, so buyers can check our claims rather than take them on faith. Every serious security vendor asserts that its systems are secure, and no honest one can promise that any system is unbreakable. RankShieldMD makes a narrower, testable claim instead: that its proofs can be recomputed by anyone, using standard tools and public keys, without access to our systems and without trusting us. That is the ownable property, and it is deliberately not "unhackable" or "100% secure." Two principles govern the design, and we hold to both plainly: verify, don't assert — a control the buyer can check is worth more than a promise the buyer has to believe — and stay PHI-free by construction, so protected health information never enters the system and there is nothing sensitive to breach. RankShieldMD is standards-first on purpose: it is built to be a reference implementation others can audit, not a proprietary silo that asks for trust.
Where this page names a standard, it names one RankShieldMD is built to. We do not claim certifications we do not hold; where one is not in place, we omit it rather than imply it.
How is RankShieldMD itself secured?
By making verification, not trust, the primary control at every layer, and by holding no protected data that a breach could expose. RankShieldMD is engineered so that no single component is trusted blindly. Inbound requests are signed with RFC 9421 signed HTTP messages, so the platform can cryptographically confirm who sent each call rather than relying on a bearer token that anyone could replay; a request that is not correctly signed is rejected before it can act. The evidence RankShieldMD produces is sealed to an append-only, RFC 6962-style transparency log whose current state is published as a signed tree head, and that root is anchored to an external record so its state at a given moment is fixed outside our sole control. Digests, model fingerprints, credentials, and identities are what flow through the system; raw patient data is rejected at the guard and never recorded, which means the ledger is useless to anyone who steals it because there is no protected content inside. The effect of these choices together is a platform whose own integrity can be checked from the outside: instead of asking a customer to believe our internal controls are sound, RankShieldMD exposes the signed, anchored, tamper-evident structure that lets them confirm it. That is the honest version of "secure" — not a claim that intrusion is impossible, which no vendor can make, but a design in which the evidence survives scrutiny and holds nothing worth stealing.
What post-quantum cryptography does RankShieldMD use?
Composite post-quantum signatures — ML-DSA-65 paired with Ed25519 — chosen so that evidence stays defensible whichever way cryptography evolves, and aligned with the NIST post-quantum standards. Signing with both a post-quantum and a classical algorithm at once is deliberate: a verifier can trust the ML-DSA-65 half, the Ed25519 half, or both, so a proof does not become worthless the moment one algorithm generation is superseded. This aligns with the NIST post-quantum cryptography standards published as FIPS 203 (ML-KEM, for key establishment), FIPS 204 (ML-DSA, the signature scheme RankShieldMD uses), and FIPS 205 (SLH-DSA, a hash-based alternative). The reason this matters in healthcare is a matter of time. Records and the evidence attached to them are retained for decades, well within a realistic window in which a capable quantum computer could threaten today's classical cryptography. There is a specific, documented threat pattern — "harvest now, forge later" — in which an adversary copies today's classically-signed evidence and waits for the tools to forge or repudiate it retroactively; long-retention healthcare records are an attractive target precisely because they are kept so long. Composite post-quantum signatures counter that by making the evidence unforgeable now and defensible later. We state the posture honestly: it is quantum-safe, not quantum-proof. No quantum computer capable of breaking current cryptography exists yet, and no one can guarantee any system is unbreakable; what RankShieldMD does is build to the standards so a decade of evidence stays defensible, and stay crypto-agile so the algorithms can rotate as those standards advance.
How is the transparency ledger tamper-evident and externally anchored?
By using the same append-only Merkle-tree construction that underpins certificate transparency, and by pinning its root outside our sole control. The transparency log is RFC 6962-style: every entry is hashed and chained into a Merkle tree, and the state of the whole log is summarized by a single tree root. That structure is what makes tampering evident rather than merely discouraged. Altering, reordering, or removing any past entry changes the hashes above it and therefore changes the root, so a log that has been quietly rewritten cannot present the same root it did before. RankShieldMD publishes the current root as a signed tree head, so the log's state at a point in time is a signed, checkable fact rather than an internal detail. External anchoring closes the remaining gap. Left to itself, an operator who controlled the log could in principle rewrite history and re-sign a fresh root that looks internally consistent. To prevent that, RankShieldMD periodically commits the signed tree head to an external record, fixing the log's state at that moment in a place we do not solely control. Any later attempt to present a different history would have to match an anchored root it cannot reproduce, so the divergence is detectable by anyone comparing the two. The practical consequence for a customer is strong: you do not have to trust that RankShieldMD never edited its own records. You can prove it, because the combination of hash-chained entries, signed tree heads, and external anchoring turns "we didn't tamper with this" from an assertion into something an outside party can independently confirm. This is the transparency-log discipline that lets the evidence survive an adversarial review, which is exactly the situation in which a healthcare record's provenance matters most.
How can we independently verify RankShieldMD's security claims?
By recomputing the evidence yourself — that is the entire point of the design, not an afterthought. Every proof RankShieldMD produces ships as an evidence package that anyone holding it can verify with standard tools, without access to our systems and without trusting RankShieldMD. Verification has three checkable parts, and none of them require a private relationship with us. First, recompute the hash chain: rebuild the digests from the package and confirm they chain to the value recorded in the log. Second, confirm the composite post-quantum signature over the entry using the published ML-DSA-65 and Ed25519 public keys, which proves the evidence was signed by the expected party and has not been altered field by field. Third, check inclusion against the signed tree head and confirm that tree head against the externally anchored root, which proves the entry is genuinely part of the log's history and that the history itself has not been rewritten. If any field has been changed, if the signature does not verify, or if the entry is not actually included under the anchored root, verification returns false and names the discrepancy. This is what "verify, don't assert" means in practice, and it is why RankShieldMD leans on published standards — RFC 6962-style logging, RFC 9421 signed requests, NIST FIPS 203/204/205 signatures, and the IETF RATS verifier role — rather than a proprietary scheme. Standards-first design is what makes RankShieldMD auditable as a reference implementation instead of a silo: a reviewer can check the work against public specifications they already trust, using tools they already have, and reach their own conclusion. The claim we stand behind is not that our systems can never be attacked. It is that our security evidence is verifiable, and that is a property you can test today.
What we are careful never to claim.
Not "unhackable"
No honest vendor can promise a system is unbreakable or 100% secure. RankShieldMD claims something testable instead: that its evidence is verifiable. You check it; you do not take it on faith.
Quantum-safe, not quantum-proof
No quantum computer capable of breaking today's cryptography exists yet. RankShieldMD builds to the NIST post-quantum standards so evidence stays defensible; it never claims an attack is impossible.
Standards built-to, not certs implied
We describe the standards RankShieldMD is built to and its honest posture. We do not assert certifications we do not hold; where one is in progress we say so, otherwise we omit it.
Ask RankShieldMD about its security posture.
What is RankShieldMD's core security claim?
That its evidence is verifiable, not that its systems are unbreakable. Every proof RankShieldMD produces ships with a recipe anyone can run to recompute the hash chain and confirm the post-quantum-signed root, using standard tools, without trusting us. We do not claim to be unhackable or 100% secure; no honest vendor can. The ownable, checkable claim is that you can verify our security evidence yourself.
Does RankShieldMD hold protected health information?
No. RankShieldMD is PHI-free by construction. It seals digests, model fingerprints, credentials, and identities — never raw patient data, which is rejected at the guard before anything is recorded. Adopting it shrinks your PHI footprint rather than growing it, because the ledger is useless to anyone who steals it: there is no protected data inside.
How is RankShieldMD itself secured?
Requests are signed with RFC 9421 signed HTTP messages so the platform can verify who sent each call. Evidence is sealed to an append-only, RFC 6962-style transparency log with signed tree heads, and the log root is anchored to an external record so it is pinned in time. The design assumes no single component is trusted blindly: verification, not assertion, is the control.
What cryptography does RankShieldMD sign with?
Composite post-quantum signatures: ML-DSA-65 paired with Ed25519. Signing with both means a verifier can trust the classical half or the post-quantum half, so evidence stays defensible whichever way cryptography evolves. This aligns with the NIST post-quantum standards, FIPS 203 (ML-KEM), 204 (ML-DSA), and 205 (SLH-DSA).
Is RankShieldMD quantum-proof?
No. It is quantum-safe, not quantum-proof. No quantum computer capable of breaking today's cryptography exists yet, and no honest vendor can guarantee any system is unbreakable. What RankShieldMD does is build to the NIST post-quantum standards so evidence created now stays defensible against "harvest now, forge later," where an adversary keeps today's signed evidence to forge it once a capable quantum computer arrives.
What is crypto-agility, and why does it matter here?
Crypto-agility is the ability to rotate cryptographic algorithms without rebuilding the system. RankShieldMD's composite signatures and versioned credentials are designed so algorithms can rotate as standards advance. That matters because healthcare evidence is retained for decades: a proof must stay verifiable long after the algorithm that created it is superseded, which requires the ability to migrate forward safely.
What makes the transparency log tamper-evident?
It is an append-only, RFC 6962-style Merkle log — the same construction that underpins certificate transparency. Each entry is chained by hash, so altering or removing any past entry breaks the chain and changes the tree root. The current root is published as a signed tree head, so a tampered or forked log is detectable by anyone who checks. You do not have to trust that we did not edit history; you can prove it.
What does external anchoring add?
It pins the log root in time. RankShieldMD periodically commits the signed tree head to an external record, so the state of the log at a given moment is fixed in a place we do not solely control. That closes the gap where an operator might try to rewrite history and re-sign a new root: the externally anchored root is the reference the new one would have to match, and it will not.
Which standards is RankShieldMD built to?
It aligns with the NIST post-quantum cryptography standards (FIPS 203/204/205), RFC 6962-style transparency logging, RFC 9421 signed HTTP requests, and the IETF RATS verifier role for remote attestation. We describe the standards RankShieldMD is built to; we do not claim certifications we do not hold. Where a certification is not in place, we say so rather than imply it.
What is the IETF RATS verifier role?
RATS (Remote ATtestation procedureS) defines an architecture in which an attester makes a claim, a verifier checks it against a policy, and a relying party acts on the verifier's result. RankShieldMD is designed to operate as the verifier: it checks attestations and produces appraisals that others can rely on, rather than asking anyone to take a claim on faith.
How can we verify RankShieldMD's claims independently?
Each evidence package is recomputable. Anyone holding it can recompute the hash chain, confirm the composite post-quantum signature, and check the entry against the signed tree head and the externally anchored root, using standard tools, without access to our systems and without trusting RankShieldMD. Verification is the deliverable: the point of the design is that you check it yourself.
What happens if evidence is altered after the fact?
Verification returns false. The signature covers every field and the log entry is chained into the Merkle tree, so changing a digest, a timestamp, or a credential breaks the cryptographic seal or the inclusion proof. A verifier holding only the public keys and the anchored root can detect the discrepancy without any private relationship with us.
Do you hold SOC 2, HITRUST, or ISO 27001 certification?
We describe the standards RankShieldMD is built to and its honest security posture rather than assert certifications we were not told we hold. Where a formal certification is in progress, we say "in progress"; where it is not, we omit it rather than imply it. The claim we stand behind is architectural and checkable: the evidence is verifiable, and PHI never enters the system.
Why is "verifiable" the claim instead of "secure"?
"Secure" is an assertion the buyer has to take on trust, and no vendor can honestly promise a system is unbreakable. "Verifiable" is a property you can test: it shifts the question from "do you believe us?" to "can you check it?" — and the answer is yes, with standard tools and public keys. Standards-first design is what makes RankShieldMD a reference implementation others can audit, not a silo that asks for faith.
Turn "trust us" into "verify us."
Bring your toughest reviewer. Register a baseline, run evidence through the same path, and check it with your own tools.