# Self-reported trust vs. verifiable security | RankShield > The worst security failures come from trusting claims no one checks. Self-reported trust is the vulnerability; verifiable security is the fix. > > Source: https://rankshield.co/resources/self-reported-trust-verifiable-security/ · RankShield (the verifiable, quantum-safe AI security platform) Resources / Foundations # Self-reported trust is the vulnerability: the case for verifiable security A surprising share of the internet’s worst attacks share one root cause: a system that trusts a claim it never verifies. Here is why self-reported trust breaks security, and why verifiable proof is the durable fix. July 17, 2026 · 13 min read · verifiable security Jamie Kloncz Founder & CEO, RankShield Share RankShield is a verifiable AI and quantum security platform, built on a single idea: a security claim you cannot independently check is not security, it is hope. That idea has a name in this article, verifiable security, and it stands against a quiet failure mode behind a startling share of real-world attacks. Call it self-reported trust: a system accepts a claim as true because something asserted it, with no way to verify whether the claim is actually true. A sensor reports its position, a router announces a route, a mail server names its sender, a network node advertises its rank, and the receiver believes it because nothing forces proof. When the claim is honest, everything works. When an attacker supplies a false claim, the system reorganizes itself around a lie it had no means to catch. A 2026 study in the journal Computer Networks framed one instance of this with unusual clarity: a widely used protocol is vulnerable precisely because it relies on a self-reported value to maintain its structure, with no central verification authority ([Hunde and Ismail, Computer Networks, 2026](https://doi.org/10.1016/j.comnet.2026.112375)). This article walks through why self-reported trust is so dangerous, where it keeps reappearing, and what it looks like to replace belief with proof. Key takeaways - Self-reported trust is a system accepting a claim (a rank, a route, a sender, a status) because something asserted it, with no independent way to verify it is true. - It is the failure mode behind some of the internet’s most damaging attacks: IoT rank attacks, BGP route hijacks, email spoofing, and DNS poisoning all exploit an unverified, self-reported signal. - A 2026 Computer Networks study (coincidentally also titled RankShield, by unrelated researchers) traces IoT routing collapse to exactly this: a protocol that trusts a self-reported rank with no central verification authority. - Detection helps but is gameable and noisy; the durable fix is verification, which makes the signal itself independently checkable so a lie is rejected rather than merely flagged. - Verifiable security reduces and contains these attacks and produces evidence you can check; it does not eliminate the possibility of a lie, it makes lies detectable and rejectable. - RankShield’s answer is to make security claims verifiable, anchored in post-quantum signatures (NIST’s ML-DSA), so you never have to take “trust us” at face value. ## What is self-reported trust, and why is it dangerous? Self-reported trust is when a system treats a claim as true because the claimant asserts it, without any independent check. A device says where it sits in a network, a server names the domain it is sending from, a node advertises its distance to the root, and the receiver acts on that assertion as if it were verified fact. The design is not careless; it is a trade. Verifying every claim costs computation, coordination, and sometimes cryptography, so many foundational protocols were built to trust first and verify never, because at the time the network was small, closed, or assumed friendly. The danger is that a self-reported value is the cheapest possible lie with the largest possible blast radius. An attacker does not need to break encryption or overwhelm the network; they only need to assert something false that the protocol has no way to question. And unlike a flood that causes temporary congestion, corrupting a self-reported structural value can permanently distort the shared state that every other participant depends on. The Computer Networks study makes this contrast directly: manipulating a self-reported metric corrupts the network’s logical hierarchy in a way that resource-flooding attacks do not, because it exploits the core logic the protocol uses to organize itself ([Hunde and Ismail, 2026](https://doi.org/10.1016/j.comnet.2026.112375)). This is why modern security doctrine moved the other way. NIST’s Zero Trust Architecture is built on the premise that no implicit trust should be granted to an asset or account based on its location, its network, or its ownership, and that authentication and authorization should happen before access is granted rather than being assumed ([NIST SP 800-207](https://csrc.nist.gov/pubs/sp/800/207/final)). Self-reported trust is the exact posture zero trust exists to correct: implicit belief in an asserted value. The fix is not to distrust everything paranoically; it is to make the important claims verifiable, so trust is earned by proof rather than granted by default. ## Why do attackers target a self-reported metric first? Because it is the highest-impact lie available in the system. Consider the protocol at the center of the 2026 study: RPL, the IPv6 Routing Protocol for Low-Power and Lossy Networks, which organizes the constrained devices that make up much of the Internet of Things. RPL builds and maintains its topology using a value called Rank, a node’s position relative to the network’s root, which strictly decreases as you move toward that root ([RFC 6550](https://www.rfc-editor.org/rfc/rfc6550)). Rank is how every node decides who its parent is and how packets flow upward. Critically, each node reports its own Rank, and its neighbors trust that report; there is no central authority checking whether the number is honest ([Hunde and Ismail, 2026](https://doi.org/10.1016/j.comnet.2026.112375)). A rank attack is simply a malicious node advertising a false Rank. Because neighbors believe the self-reported value, they reorganize the routing structure around the lie: they may route through the attacker, form loops, or abandon good paths. The damage is not theoretical. The study measured a rank attack driving roughly a 75% increase in node energy consumption, as devices stayed awake to handle the excess control traffic the corrupted topology generated ([Hunde and Ismail, 2026](https://doi.org/10.1016/j.comnet.2026.112375)). In battery-powered sensor networks, that is not an inconvenience; it shortens the life of the deployment. The instructive part is what the attack did not require. It did not break cryptography, it did not flood the network into collapse, and it did not need special access. It told one lie the protocol had no mechanism to check. That is the signature of a self-reported-trust vulnerability: minimum effort, maximum structural consequence. The chart below shows both the cost of the attack and how much a purpose-built defense recovered, which sets up the deeper question of what kind of defense actually holds. MEASURED IN A 2026 STUDY ### One self-reported lie, and the defense that answers it Node energy use under an RPL rank attack +75% Latency, with the study’s hybrid defense 66% lower Energy use, with the defense 45% lower Packet delivery ratio, with the defense 67% higher Source: Hunde and Ismail, Computer Networks (2026). The attack figure is the energy cost of the corrupted topology; the other three are recoveries reported for their detect-and-verify defense. ## Where else does self-reported trust break security? Nearly everywhere a protocol was designed to trust an assertion, which is to say across the foundations of the internet itself. The IoT rank attack is a small, clear instance of a pattern that also operates at global scale. Three examples show the same shape, and the same fix. Routing: BGP, the protocol that steers traffic between networks, works by having each network announce which address ranges it can reach, and by default its neighbors accept the announcement. A false announcement, a route hijack, can quietly divert a large share of internet traffic through an attacker. The answer is verification: the Resource Public Key Infrastructure lets the legitimate holder of an address block explicitly and verifiably authorize which networks may originate routes to it, so a receiver can check an announcement instead of believing it ([RFC 6480](https://www.rfc-editor.org/rfc/rfc6480)). Email: SMTP lets a sender put any domain in the From field, and for decades receivers believed it, which is the root of spoofing and most phishing. The fix, again, is proof. DomainKeys Identified Mail lets a domain cryptographically sign a message so a receiver can verify it was authorized by that domain and was not altered in transit ([RFC 6376](https://www.rfc-editor.org/rfc/rfc6376)). DMARC ties signing and sender checks to a published policy, so a receiver can decide what to do with mail that claims a domain but cannot prove it ([RFC 7489](https://www.rfc-editor.org/rfc/rfc7489)). Naming: a DNS resolver historically trusted whatever answer it received, so a poisoned answer could send users to an attacker’s server while the address bar looked correct. DNSSEC adds data-origin authentication and integrity, letting a resolver cryptographically verify that a DNS answer came from the right source and was not tampered with ([RFC 4033](https://www.rfc-editor.org/rfc/rfc4033)). The pattern across all four cases is identical: a self-reported signal, an attack that supplies a false one, and a fix that replaces belief with a check. DOWNLOADABLE INFOGRAPHIC ### The self-reported trust failure, across four systems The same flaw, from an IoT sensor to the global internet: a trusted claim, a false one, and verification as the fix. Free to share with attribution. ## Is detection enough, or do you also need verification? Detection is necessary, but it is not sufficient on its own. Detection watches a system for anomalies and flags what looks wrong, often with machine learning; it is exactly the first stage of the defense in the Computer Networks study, where a deep neural network classifies abnormal rank behavior before anything else happens ([Hunde and Ismail, 2026](https://doi.org/10.1016/j.comnet.2026.112375)). Good detection catches a great deal, and every serious security system needs it. The problem is that detection has two structural limits when it stands alone. The first limit is that detection can be gamed, because it reasons about signals the attacker often controls. The same study cautions that indicators such as reported energy levels can be falsified by an attacker while legitimate workload swings trip false alarms, which is why detection built on self-reported inputs inherits the very weakness it is trying to police. The second limit is noise: a detector tuned to catch subtle attacks will also flag benign variation, and a detector tuned to avoid false alarms will miss quiet attacks. That is why the study does not let its neural network act alone; it pairs the detector with a deterministic second check that confirms a verdict before the system isolates anything, precisely to reduce unnecessary alarms ([Hunde and Ismail, 2026](https://doi.org/10.1016/j.comnet.2026.112375)). Verification is the stronger form of that second idea. Rather than guessing after the fact whether a claim was a lie, verification makes the claim carry proof, so a claim that cannot be proven is simply rejected. Detection asks “does this look wrong?” and answers with a probability; verification asks “can this be proven right?” and answers with a check. The honest boundary matters here, because this is a place where security marketing overreaches: verification does not eliminate attacks. A determined adversary can still refuse to prove, or move to attack something else. What verification removes is the cheap, high-impact lie, by making “trust me” insufficient on its own. DETECTION VS. VERIFICATION ### Two ways to answer a suspicious claim | | Detection alone | Detection plus verification | | --- | --- | --- | | Core question | Does this look wrong? | Can this be proven right? | | Output | A probability, after the fact | A check, before you act on it | | If the attacker controls the signal | Can be shaped to look normal | Cannot forge a valid proof | | False alarms | Benign variation trips it | Unproven claims are simply rejected | | What survives a determined attacker | May miss a quiet lie | Removes the cheap lie; attacker must work harder | ## What does verifiable security actually look like? It looks like every important claim shipping with evidence that anyone can check, without having to trust the party that made it. That is a real, defined discipline, not a slogan. The IETF formalized it as remote attestation: an Attester produces evidence about its own state, a Verifier appraises that evidence and issues a result, and a Relying Party acts on the appraised result rather than on a bare assertion ([RFC 9334](https://www.rfc-editor.org/rfc/rfc9334)). The whole point of the architecture is to separate “claims a system makes about itself” from “claims a third party has checked,” which is the exact separation self-reported trust collapses. RankShield is built around that separation. It seals important actions and claims as tamper-evident records designed so a third party can verify them independently, so the answer to “is this real?” is “check it yourself,” not “trust us.” The proofs are anchored in post-quantum cryptography: signatures use NIST’s standardized ML-DSA ([FIPS 204](https://csrc.nist.gov/pubs/fips/204/final)), and key establishment uses ML-KEM ([FIPS 203](https://csrc.nist.gov/pubs/fips/203/final)), so the evidence stays quantum-safe as cryptography changes. The claim we make about this is deliberately bounded: verifiable evidence reduces and contains attacks that rely on unchecked claims, and it produces a record you can use later; it does not make a system unbreakable, and no honest security product should say otherwise. You can see the mechanism on the [attestation API](https://rankshield.co/platform/attestation-api/), and the broader posture on the [platform overview](https://rankshield.co/platform/). One honest aside, because we cite it throughout. The 2026 study anchoring this article is also titled RankShield, written by Eden Teshome Hunde and Shereen Ismail in Computer Networks, researchers we have no connection to and had never met ([Hunde and Ismail, 2026](https://doi.org/10.1016/j.comnet.2026.112375)). The shared name is a coincidence, and we cite the work precisely because it is independent of us. Two teams, in different fields, reaching for the same shield metaphor and the same conclusion: a self-reported metric with no way to verify it is the thing that breaks, and adding a way to check it is the thing that helps. When the same answer shows up in an IoT routing lab and in a platform for AI and agent security, that is a signal the principle is real, not marketing. For the agent case specifically, see how the same idea applies to autonomous software in [how to verify an autonomous agent](https://rankshield.co/resources/how-to-verify-an-autonomous-agent/). ## How can you tell if a security claim is verifiable? Ask one question of every security claim you rely on: can I check this myself, without trusting whoever made it? If the only answer is “because the vendor says so” or “because the record we keep says so,” you are looking at self-reported trust wearing a security label. A few concrete tells separate the two, and they map directly onto the attestation model of Attester, Verifier, and Relying Party ([RFC 9334](https://www.rfc-editor.org/rfc/rfc9334)). Run a claim past the checklist below. The more “no” answers you collect, the more of your security posture is really just belief, and belief is exactly what an attacker with a false claim is counting on. The goal is not to verify everything, which is impractical; it is to make sure the high-impact claims, the ones an attacker would most want to fake, are the ones carrying proof. - Independent check: can a third party confirm the claim, or does confirmation require trusting the party that made it? - Tamper-evidence: if the underlying record were altered, would you be able to tell? - Cryptographic anchor: is trust rooted in a signature or attestation, or only in a vendor’s assertion? - Quantum-safe proofs: will the evidence still be verifiable against a future quantum adversary (ML-DSA, ML-KEM), or does it rest on cryptography with a shelf life? - Bounded honesty: does the claim say it reduces, contains, and evidences, or does it promise to eliminate, guarantee, or make something unhackable (a tell that it cannot be verified)? SELF-CHECK ### Is your security self-reported or verifiable? - For your most critical security claims, can a third party verify them without trusting you? - If a key security record were altered, would you detect it? - Is trust in your systems anchored in cryptography or in assertions? - Are your proofs quantum-safe (post-quantum signatures/KEM)? - Do your security claims describe what they reduce and evidence, not what they “eliminate”? ## The bottom line: trust that cannot be checked is only hope The through-line from an IoT sensor losing 75% of its battery to a rank attack, to a hijacked internet route, to a spoofed email, is not that these systems were badly built. It is that each one trusted a claim it had no way to verify, and an attacker supplied a false one. The fix in every case was the same move, arrived at independently by different communities: stop believing the claim, and start checking it. That is what verifiable security means, and it is the one claim RankShield makes that is literally true rather than merely confident: not that we are unbreakable, but that you do not have to take our word for it. Reducing, containing, and evidencing attacks that rely on unchecked claims is a bounded, honest promise, and it is a far better foundation than hoping every claim you depend on happens to be honest. FREQUENTLY ASKED ## Questions, answered. Jamie Kloncz CEO, RankShield · online What is self-reported trust in security? Self-reported trust is when a system treats a claim as true simply because the claimant asserts it, with no independent way to verify it. A network node reports its position, a router announces a route, a mail server names its sender, and the receiver acts on the assertion as verified fact. Many foundational protocols were built this way as a trade: verifying every claim costs computation and coordination, so early designs trusted first and verified never. The weakness is that a self-reported value is the cheapest lie with the largest blast radius, because an attacker only has to assert something false that the protocol has no mechanism to question. It is the exact posture that zero trust and verifiable security exist to correct. What is a rank attack, and how does it relate to self-reported trust? A rank attack targets RPL, the routing protocol for low-power IoT networks, which maintains its topology using a self-reported value called Rank that indicates a node’s position relative to the root (RFC 6550). Each node reports its own Rank and its neighbors trust it, with no central authority checking whether the number is honest. A malicious node advertises a false Rank, and because neighbors believe it, they reorganize routing around the lie, causing loops, packet loss, and wasted energy. A 2026 Computer Networks study measured a rank attack driving roughly a 75% increase in node energy use. It is a clean example of a self-reported-trust vulnerability: minimum attacker effort, maximum structural damage, no cryptography broken. Is verifiable security the same as zero trust? They are closely related but not identical. Zero trust is a security model that removes implicit trust based on location, network, or ownership and requires authentication and authorization before access (NIST SP 800-207). Verifiable security is the mechanism that makes that possible for claims rather than just access: it makes a claim carry independently checkable proof, so a relying party acts on verified evidence instead of an assertion. The IETF formalizes this as remote attestation, with an Attester, a Verifier, and a Relying Party (RFC 9334). In short, zero trust says do not trust by default; verifiable security is one of the concrete ways you replace that default trust with proof. Can verification eliminate these attacks? No, and any product claiming to eliminate attacks or be unhackable is overselling. Verification does not make a system impossible to attack; a determined adversary can refuse to provide proof, exploit an unrelated weakness, or attack a component that was never made verifiable. What verification does is remove the cheap, high-impact lie by making an unproven claim insufficient on its own, so an attacker can no longer simply assert something false and be believed. The honest framing is that verifiable security reduces and contains attacks that depend on unchecked claims, and produces evidence you can use afterward. That is a bounded, achievable outcome, and it is far stronger than hoping the claims you depend on are honest. Why does post-quantum cryptography matter for verifiable security? Because verifiable security depends on cryptographic proof, and a proof is only as durable as the cryptography behind it. If the signatures and key exchange protecting your evidence can be broken by a future quantum computer, then evidence you rely on today could be forged or exposed later. That is why RankShield anchors its proofs in NIST’s standardized post-quantum algorithms: ML-DSA for signatures (FIPS 204) and ML-KEM for key establishment (FIPS 203). The correct word is quantum-safe, not quantum-proof: these standards are designed to resist known quantum attacks, and using them keeps verifiable evidence checkable as the cryptographic ground shifts. Quantum-safe proofs are what let a verification made today still mean something years from now. Is the RankShield in the Computer Networks paper the same as RankShield the platform? No. The 2026 Computer Networks study titled RankShield is an academic framework for detecting and mitigating RPL rank attacks in IoT networks, written by Eden Teshome Hunde and Shereen Ismail, researchers with no connection to this company. The shared name is a genuine coincidence. We cite the paper precisely because it is independent of us: it reaches the same conclusion we build on, that a self-reported metric with no way to verify it is the thing that breaks, and that adding a verification step is what helps. When the same principle turns up independently in an IoT routing lab and in a platform for AI and agent security, that is evidence the idea is sound rather than a marketing line. The name collision is a curiosity; the shared conclusion is the point. ## References - [Hunde & Ismail — RankShield: hybrid detection and mitigation of RPL rank attacks, Computer Networks (2026)](https://doi.org/10.1016/j.comnet.2026.112375) - [IETF RFC 6550 — RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks (Rank metric)](https://www.rfc-editor.org/rfc/rfc6550) - [IETF RFC 6480 — An Infrastructure to Support Secure Internet Routing (RPKI)](https://www.rfc-editor.org/rfc/rfc6480) - [IETF RFC 6376 — DomainKeys Identified Mail (DKIM) Signatures](https://www.rfc-editor.org/rfc/rfc6376) - [IETF RFC 7489 — Domain-based Message Authentication, Reporting, and Conformance (DMARC)](https://www.rfc-editor.org/rfc/rfc7489) - [IETF RFC 4033 — DNS Security Introduction and Requirements (DNSSEC)](https://www.rfc-editor.org/rfc/rfc4033) - [IETF RFC 9334 — Remote ATtestation procedureS (RATS) Architecture](https://www.rfc-editor.org/rfc/rfc9334) - [NIST SP 800-207 — Zero Trust Architecture](https://csrc.nist.gov/pubs/sp/800/207/final) - [NIST FIPS 204 — Module-Lattice-Based Digital Signature Standard (ML-DSA)](https://csrc.nist.gov/pubs/fips/204/final) - [NIST FIPS 203 — Module-Lattice-Based Key-Encapsulation Mechanism Standard (ML-KEM)](https://csrc.nist.gov/pubs/fips/203/final) WRITTEN BY ## [Jamie Kloncz](https://rankshield.co/author/jamie-kloncz/) Founder & CEO, RankShield Jamie Kloncz is the founder and CEO of RankShield, the verifiable AI and quantum security platform. He started the company after two attacks landed in a single week: his phone was cloned, and his business was hit by a click-fraud campaign. One targeted him as a person, the other his livelihood, and no single tool defended both. That experience, together with surviving an AI voice-clone scam, shaped RankShield’s core belief: the threats of the AI age are personal first, and trust should be something you can check, not just extend. More from Jamie → ## Make every AI action provable. RankShield is the verifiable, quantum-safe AI security platform — protection you can check, not just trust. Explore the platform → Get started ## More from Resources Traffic Integrity Do you need edge protection if you already have a security plugin? Your plugin guards the server. The edge guards the road to it. The difference is not philosophical, it is physical: a plugin can only act after a request has already reached your hosting and spent its resources. Traffic Integrity Impressions but no clicks in Google Search Console: is it bots, or is it your own rank tracker? A page with thousands of impressions and zero clicks looks like sabotage. We pulled 16 months of our own Search Console data and our own edge logs to find out. The machines were real. The attack was not. Threat Intelligence Day one on the network: what a shared threat intelligence network already knows before your site is ever attacked A new site has no attack history of its own, and attackers do not wait for it to build one. Here is first-party data on what joining a shared threat intelligence network actually buys you: 1,030,648 threat events recorded across the RankShield network in 28 days, from 11,691 networks, all of it knowledge a site inherits on its first request.