# Security Architecture and Standards

> The standards under RankShield Legal: NIST FIPS 204/205 post-quantum signatures, RFC 6962 transparency logs, IETF RATS verification, and honest data handling.

[Home](https://rankshieldlegal.com/) / Security & standards Security & standards
# Built on the standards, not a private scheme.
**RankShield Legal anchors to public standards** — NIST post-quantum signatures, RFC 6962 transparency logs, IETF RATS attestation — so its proofs are checkable with open tooling rather than proprietary trust. This page states plainly what we use, what we store, what we refuse to store, and where the honest edges are.
[Try the citation checker](https://rankshieldlegal.com/ai-legal-citation-checker/) [Request early access](https://rankshieldlegal.com/contact/)

## Which public standards does RankShield Legal build on?
Every claim this platform makes about a record is meant to be verifiable by someone who does not trust RankShield. That is only possible if the underlying machinery is public. So the architecture is assembled from standards that a firm's security or IT owner can read, audit, and check against independent implementations, rather than a house cryptosystem we ask you to take on faith.
The four load-bearing standards are named below. Two are cryptographic (how records are signed and how they are logged), one is architectural (how verification authority is structured), and one is the obligation layer the outputs are designed to support. Each is a document you can pull and read for yourself; none of them originate with RankShield, and that is the point. Our [how-it-works walkthrough](https://rankshieldlegal.com/how-it-works/) traces one record end to end through these same standards.

- NIST FIPS 204 (ML-DSA) and FIPS 205 (SLH-DSA) — composite post-quantum signatures on every certificate and attestation. Classical RSA and ECDSA face deprecation after 2030 under NIST IR 8547, so records that must outlive that horizon are signed with algorithms designed to survive it.
- RFC 6962 — Merkle transparency logs: append-only, hash-chained, and independently verifiable. Every sealed record gets an inclusion proof that anyone can check against the public log head without asking us for permission.
- IETF RATS (RFC 9334) — the remote-attestation architecture that defines the roles in a verification system. RankShield operates as the Verifier and trust anchor, producing attestation results about the evidence it is shown.
- FRCP Rule 11 and court AI standing orders — the obligations the certification outputs are designed to support. The outputs give a filer verifiable evidence to point at; they do not discharge the duty on the filer's behalf.

## Why anchor to public standards instead of a proprietary trust scheme?
A proprietary trust scheme has a structural weakness that no amount of engineering removes: to believe its output, you have to believe the vendor. If RankShield invented its own signature format and its own log and asked courts, opposing counsel, and your own risk committee to accept them because we vouch for them, then the evidence would only ever be as strong as our reputation on the day someone challenged it. That is a fragile foundation for records that may need to hold up years after they were created.
Public standards invert that. When a certificate is signed with a NIST-standardized algorithm and logged in an RFC 6962 structure, a skeptic does not need our cooperation to test it. They can take the receipt, run an open-source verifier, and reach their own conclusion. The trust moves out of the vendor and into mathematics and published specifications that a third party can implement independently. This is the difference between asking you to trust a dashboard and giving you something checkable in the open, which is the theme of our [why-verifiable overview](https://rankshieldlegal.com/why-verifiable/).
There is a practical durability argument too. Standards are maintained by bodies with long horizons and broad review — NIST, the IETF — and their formats are implemented in many places. A record built on them remains checkable even if RankShield is not in the room, not under contract, or not in business. A proprietary format dies with its vendor. For legal records, whose retention and confidentiality obligations routinely outlast the technology that created them, that longevity is not a nicety; it is the requirement.

## What does a certificate actually contain — and what does it deliberately leave out?
A RankShield Legal certificate is designed to prove something about a record without carrying the record. It stores digests — cryptographic hashes that stand in for content without revealing it — alongside the verdict of whatever check was run, public citation metadata, and coverage indicators that describe how complete that check could be. What it does not store is the substance: no privileged content, no filing text, no client material. The design principle is proof-without-exposure, and it is enforced by what goes into the certificate in the first place, not by an access-control setting layered on afterward.
Concretely, that means a certificate can attest that a given document was checked against a corpus of case law and record what the check found, while the document itself never enters our systems in readable form. A digest is a one-way function of the input; you cannot reconstruct the brief, the memo, or the client's name from it. The verdict and coverage indicators travel with the digest so that a later reader understands both what was found and how far the check could see.
Coverage indicators deserve emphasis because they are where honesty gets built into the data model. Where a check depends on an external source — live case law, or your firm's own citator — that dependency and its coverage are recorded alongside the result rather than hidden behind a confident-looking checkmark. A reader can therefore tell the difference between "checked against a complete corpus" and "checked against what was reachable at the time," which are very different claims that a naive system would present identically.

## What do privilege attestations store, and how are they kept separate?
Privilege attestations answer a narrower question than certificates: they attest to the architecture and the consent under which a workflow ran, not to the content that passed through it. So a privilege attestation stores digests and an enumerated list of the methods that were applied — which isolation steps ran, which controls were in force — and nothing more. It does not store the privileged material it was protecting. It cannot, by construction, because the material never lands in a place the attestation could read it from.
This matters because the whole value of a privilege attestation would collapse if generating it required exposing the very thing it exists to protect. An attestation that leaked privileged content in order to prove it was handled carefully would be self-defeating. The enumerated-methods model sidesteps that: the attestation is a record that specific protective steps occurred and that specific consent was given, expressed as digests and method identifiers, which is provable without disclosure. The mechanics of that isolation are described in our [privilege-isolation page](https://rankshieldlegal.com/privilege-isolation/).
It is worth being precise about the limit of this claim, because it is a limit that a firm's security owner will and should probe. A privilege attestation proves that the architecture and consent were as stated. It does not — and is not offered to — prove a legal conclusion about whether privilege attaches to any particular communication. That determination is a matter of law and professional judgment. The attestation is evidence about how something was handled, not a ruling about its legal status.

## How does post-quantum signing work here, and why composite?
Every certificate and attestation carries a composite post-quantum signature: it is signed twice, with two different algorithms that rest on two different mathematical foundations. ML-DSA (FIPS 204) is lattice-based; SLH-DSA (FIPS 205) is hash-based. The two families are not variations on one idea — they draw their security from unrelated hard problems. A record is only accepted as validly signed when both signatures check out.
The reason for the redundancy is a hedge against cryptanalytic surprise. If a future advance weakens the lattice family, the hash-based signature still stands, and vice versa. No single break takes the record with it. That kind of defense-in-depth is usually overkill for short-lived data, but legal records are not short-lived. A certificate may need to remain verifiable for decades, across a period in which the cryptographic landscape will certainly shift. Signing with two independent foundations buys margin against that uncertainty in a way a single algorithm cannot.
The choice of post-quantum algorithms specifically is tied to a published timeline rather than to marketing. NIST IR 8547 sets out a transition in which classical RSA and ECDSA are deprecated after 2030. Records signed today with those classical algorithms inherit that expiry; records signed with ML-DSA and SLH-DSA are built for the horizon on the far side of it. That said, the honest framing is quantum-safe, not quantum-proof. These are the algorithms NIST standardized to resist known quantum attacks; standardization is a strong signal, not a guarantee of permanent immunity, and we do not claim otherwise. Our [quantum-safe page](https://rankshieldlegal.com/quantum-safe-law-firms/) goes deeper on what that phrase does and does not promise.

## How does the RFC 6962 transparency log make records checkable?
A signature proves who sealed a record and that it has not changed. It does not, on its own, prove that the record existed at a particular time and was not quietly swapped or backdated later. That second guarantee is what the transparency log provides. RankShield Legal writes every sealed record into an append-only, hash-chained Merkle log built on the RFC 6962 construction — the same family of structure that underpins Certificate Transparency across the public web.
Append-only and hash-chained are the two properties that carry the weight. Append-only means entries can be added but not altered or removed without breaking the chain. Hash-chained means each entry is cryptographically bound to those before it, so tampering with any past record invalidates everything that followed and is detectable. On top of this, the log can produce an inclusion proof for any single record: a compact piece of evidence that this exact record sits in the log, checkable against a published log head without trusting the log operator's word.
The practical consequence is that the log's integrity does not depend on trusting RankShield to behave. A verifier checks the inclusion proof and the log head arithmetic themselves. If we ever tried to rewrite history, the math would not close, and independent monitors watching the log head would see it. That is the intended posture: the system is designed so that even its operator cannot silently alter the record. You can inspect the current log state directly from our [transparency page](https://rankshieldlegal.com/transparency/).

## Where does RankShield sit in the IETF RATS architecture?
IETF RATS (RFC 9334) gives remote attestation a shared vocabulary of roles, and being explicit about which role RankShield plays is part of stating the architecture honestly. In RATS terms, an Attester produces evidence about itself, a Verifier appraises that evidence against policy and issues attestation results, and a Relying Party consumes those results to make a decision. RankShield Legal operates as the Verifier and trust anchor. It appraises the evidence it is shown and produces attestation results; it is not the party that ultimately acts on them.
Naming the role this way also names its boundary. As Verifier, RankShield can attest that the evidence it received supports a stated conclusion about architecture and consent. It is not positioned to attest to things outside the evidence — it does not observe your matter, exercise legal judgment, or reach conclusions of law. The attestation result is scoped to what the evidence actually shows, and the reader who relies on it stays the Relying Party, keeping the decision and its professional responsibility with the human or firm that acts.
This separation is deliberate and worth a security owner's attention, because a common failure mode in attestation systems is a verifier that quietly overclaims — presenting an appraisal of narrow evidence as if it were a broad guarantee. Anchoring to the RATS role definitions is how we keep the claim honest: a RankShield attestation result says exactly what a Verifier is entitled to say, and no more.

## Which obligations do the outputs support — and which do they not?
The certification outputs are designed with specific real obligations in mind: FRCP Rule 11, the growing set of court standing orders governing AI use in filings, client audit demands, and professional confidentiality duties. When a rule asks a filer to certify that citations were checked or that AI-assisted work was reviewed, a RankShield certificate gives that filer verifiable evidence to stand behind the representation — evidence a court or an opposing party can independently test rather than take on assertion.
The critical distinction, and the one this page will not blur, is between supporting an obligation and discharging it. RankShield is a security vendor. Its outputs support compliance; they do not make a firm compliant, and they do not substitute for the professional judgment the obligation actually demands. A certificate can show that a citation-check ran and what it found. It cannot decide, on your behalf, that the resulting filing is sound, that the argument is well-founded, or that Rule 11's standard is met. Those judgments remain the filer's, and the certificate is evidence in service of them, not a replacement for them.
Put plainly: the outputs are built to make it easier to demonstrate that you did the work and to let others verify that demonstration. They are not a compliance service, not legal advice, and not a warranty that any particular obligation has been satisfied. The value is in producing checkable evidence at the moment of the work, so that the record exists later when someone asks for it.

## Can a record be verified without a RankShield account?
Yes, and this is the single most important property of the whole design, so it is worth stating without hedging: verification does not require a RankShield account, a login, or our cooperation. It uses the receipt itself. A receipt carries the composite post-quantum signature and the RFC 6962 inclusion proof, and those two artifacts are everything a verifier needs.
The check has two steps and both use open, documented constructions. First, verify the post-quantum signature against the record's digest, confirming the record was sealed by the stated key and has not changed. Second, verify the RFC 6962 inclusion proof against the public log head, confirming the record is present in the append-only log and was logged when it claims to have been. Neither step calls a RankShield API or consults a RankShield permission. A skeptic with the receipt and open-source tooling reaches the conclusion on their own.
This is precisely what makes the verification independent rather than a feature of our product. If checking a record required our dashboard, then the trust would still ultimately rest on us, and a determined challenger could always ask why they should believe our screen. Because the receipt is self-contained and the tooling is open, the answer is that they do not have to believe us — they can check. That is the whole reason the architecture is built on public standards instead of a private scheme.

## The honest edges
No security architecture is all guarantee and no limit, and pretending otherwise would undermine the very credibility this page is trying to earn. These are the boundaries a firm's security or IT owner should know before relying on anything here. Each one is a place where the system's honest claim is narrower than a casual reading might assume.

- Corpus-limited existence — a citation check can only speak to what was in the reachable case-law corpus at verification time. Coverage is recorded on every certificate so a reader can see how far the check could see; a clean result over a partial corpus is not the same as a clean result over a complete one.
- Good-law standing comes from your firm's citator — we surface and record what the citator reports, and we never independently assert that a case is good law. Citator resolution is only as complete as the corpus behind it.
- Attestations prove architecture and consent, not legal conclusions. A RankShield record can show that specific protective steps ran and that consent was given; it cannot rule on privilege, on the merits, or on whether a legal obligation is satisfied. That judgment stays with the professional.
- Quantum-safe is not immunity. The signatures use NIST-standardized post-quantum algorithms designed to resist known quantum attacks. No system is quantum-proof, and standardization is a strong signal rather than a permanent guarantee. We say quantum-safe, and we mean the narrower thing.
- Supporting compliance is not being compliance. RankShield is a security vendor that produces verifiable evidence. That evidence supports obligations under Rule 11, court AI orders, and confidentiality duties; it does not discharge them, and it is not legal advice.

## What is RankShield Legal, and what is it not?
To close the loop and remove any ambiguity a diligence reviewer might otherwise have to chase: RankShield Legal is a security vendor. It builds an evidence layer. Its job is to produce cryptographic proofs — certificates and attestations, signed with post-quantum algorithms and logged in a public transparency log — that let a firm and third parties verify how work was handled. That is the entire scope of what it is.
It is not a law firm. It gives no legal advice, renders no legal opinions, and forms no attorney-client relationship. It is not a compliance service; it does not certify that a firm meets any regulatory standard, and its outputs support rather than satisfy compliance obligations. It does not store privileged content or filing substance, and it is not positioned to reach conclusions of law. Where a claim would require any of those things, RankShield declines to make it, and the honest edges above spell out where those lines fall.
What remains after those subtractions is a focused and durable service: verifiable evidence, built on public standards, checkable without trusting the vendor, and designed to remain checkable for as long as the records themselves need to last. A firm's professional judgment stays in charge of every legal question. RankShield's role is narrower and more mechanical — to make sure that when someone later asks whether the work was done and how, there is a proof to point at that anyone can test.

Ask anything
## Security & standards, answered
The questions law firms ask, answered directly. **No forms, no sales pitch.**

JAMIE KLONCZ · SEO AGENCY NAPLES ************** ONLINE
Pick a question on the left, or search above. You will get the direct answer, the way an answer engine would give it.

← PREV NEXT → [REQUEST ACCESS →](https://rankshieldlegal.com/contact/)

- **Why composite post-quantum signatures instead of one algorithm?** Certificates may need to remain verifiable for decades, so each is signed twice — with ML-DSA (lattice-based, FIPS 204) and SLH-DSA (hash-based, FIPS 205). The two rest on unrelated mathematical foundations, so if future cryptanalysis weakens one family, the other still holds and the record survives the break. A record is only accepted when both signatures check out. That redundancy is usually overkill for short-lived data, but legal records carry confidentiality and integrity obligations that outlast most technology cycles, which is exactly the case where signing across two independent foundations earns its cost.
- **Can I verify a record without a RankShield account?** Yes. Verification uses the receipt itself, not our systems. Check the composite post-quantum signature against the record's digest, then check the RFC 6962 inclusion proof against the public log head. Both steps use open, documented constructions and open-source tooling, so they require no login, no API call, and no cooperation from RankShield. That independence is the point: if verification depended on our dashboard, the trust would still rest on us. Because the receipt is self-contained, a skeptic does not have to believe us — they can check the math themselves and reach their own conclusion.
- **Is RankShield Legal a law firm or a compliance service?** Neither. RankShield is a security vendor. Its outputs are designed to support compliance obligations — court AI certifications, Rule 11 representations, client audit demands, confidentiality duties — by producing verifiable evidence, but it does not give legal advice and it does not make you compliant by itself. Supporting an obligation and discharging it are different things: a certificate can show that a check ran and what it found, but it cannot decide that your filing is sound or that a legal standard is met. Your professional judgment stays in charge of every legal question.
- **What exactly does a certificate store about my documents?** Digests, verdicts, public citation metadata, and coverage indicators — never the substance. A digest is a one-way cryptographic hash that stands in for content without revealing it, so a certificate can attest that a document was checked while the document itself never enters our systems in readable form. Privilege attestations similarly store digests plus an enumerated list of the methods applied. Neither certificates nor attestations store privileged content, filing text, or client material. The design is proof-without-exposure, enforced by what goes into the record in the first place rather than by an access control added afterward.
- **What does quantum-safe mean, and does it mean my records can never be broken?** Quantum-safe means the signatures use NIST-standardized post-quantum algorithms — ML-DSA and SLH-DSA — designed to resist known quantum attacks, at a time when NIST IR 8547 has classical RSA and ECDSA slated for deprecation after 2030. It does not mean quantum-proof. No system is immune, and standardization is a strong signal rather than a permanent guarantee. We use the narrower word deliberately. The composite two-algorithm design adds a further hedge: even if one family is weakened later, the other still holds, so the record does not fall to a single cryptanalytic advance.
- **How do I know a case is still good law — does RankShield decide that?** No. Good-law standing comes from your firm's citator. RankShield surfaces and records what the citator reports; it never independently asserts that a case is good law, and citator resolution is only as complete as the corpus behind it. More broadly, citation checks are corpus-limited: a result can only speak to the case law reachable at verification time, which is why coverage is recorded on every certificate. A clean check over a partial corpus is a narrower claim than a clean check over a complete one, and the coverage indicator lets a reader tell the two apart.
- **Why build on public standards rather than a proprietary system?** Because a proprietary system can only ever be as trustworthy as the vendor behind it, and legal records outlast vendors. When a certificate is signed with NIST-standardized algorithms and logged in an RFC 6962 structure, a skeptic can verify it with independent, open-source tooling and reach their own conclusion — the trust lives in published mathematics and specifications, not in RankShield's reputation. Public standards are also maintained by long-horizon bodies like NIST and the IETF and implemented in many places, so a record stays checkable even if RankShield is not in the room, under contract, or in business.

Keep exploring
## Related
[Verify this siteExplore →](https://rankshieldlegal.com/transparency/)[How it worksExplore →](https://rankshieldlegal.com/how-it-works/)[Why verifiableExplore →](https://rankshieldlegal.com/why-verifiable/)[Privilege isolationExplore →](https://rankshieldlegal.com/privilege-isolation/)[Quantum-safe securityExplore →](https://rankshieldlegal.com/quantum-safe-law-firms/)