One assumption, four different trust mechanisms
Signing infrastructure is invisible until it fails. And when it fails, the question that comes up is rarely "what broke technically" - it's "who actually did this." JWT, mTLS, HSM-backed signing, blockchain transactions: all of them lean on the same assumption underneath. A valid signature means the matching private key produced it. What differs, completely, is how each system defends that assumption - and that's exactly where most misunderstandings start.
The assumption itself
Verification is the easy part:
Verify(signature, message, public_key) == true
RSA, ECDSA, Ed25519 - these have been picked apart by cryptographers for decades and hold up fine when implemented correctly. Nobody breaks a signing system by breaking the math.
What the equation above doesn't tell you is who the public key actually belongs to, or whether the matching private key is still sitting only where it's supposed to. Cryptography proves that a key pair produced a signature. It says nothing about identity. Everything past that point depends on something bolted on afterward: a trust anchor. And this is exactly where JWT, TLS, HSMs, and blockchain part ways.
JWT: trust whoever runs the endpoint
A JWT verifier usually doesn't hardcode anything. It pulls public keys from a JWKS endpoint the issuer exposes over HTTPS. So the trust anchor is just: whoever controls that URL.
This is convenient - rotate a key, and every service that fetches the updated JWKS starts validating against it, no manual redistribution needed. Fine for a system with a hundred internal services talking to each other.
The catch shows up at revocation. A token that's already been issued stays valid until it expires, full stop. Rotating the signing key stops future tokens from validating against the old key - it does nothing to the ones already circulating. If you need to kill a token immediately, you're reaching for a blocklist or an introspection call, because the JWT format itself has no "undo."
TLS: trust gets delegated up a chain
TLS solves the same problem by handing the decision to someone else. Your OS ships with a set of root CAs already trusted. A server's certificate chains back to one of them, and the client checks the whole chain instead of deciding on the spot whether to trust this particular server.
That's what makes TLS work at internet scale - nobody manually vets every website they visit. And unlike JWT, there's a real revocation story here: CRLs and OCSP exist precisely so a CA can say "this cert is dead" before its expiry date. In practice it's patchy - plenty of clients skip OCSP checks for speed, and CRLs go stale - but the mechanism at least exists.
The real fragility is upstream of any single certificate: the whole model assumes CAs behave. When one doesn't, the damage isn't contained to one site. DigiNotar found this out in 2011 - an intruder got into its CA servers in June, started issuing rogue certificates in July, and by the time browsers pulled the trust anchor entirely, the fraudulent certificate list ran past five hundred entries, including one for *.google.com used to intercept roughly 300,000 Iranian Gmail accounts.[1] DigiNotar was bankrupt within weeks. Not because the crypto broke - because the organization behind the trust anchor did.
HSMs: trust a physical boundary instead of a person
Hardware Security Modules take a different angle entirely: don't worry about distributing public keys, just make sure the private key physically never leaves the device unencrypted. An application can't read it off disk or memory - it sends a signing request in, the HSM signs internally, and only the signature comes back out.
Key rotation is well-supported here too - generate new keys inside the boundary, retire old ones, all through a standard interface like PKCS#11.
Here's the part that surprised me the first time I actually worked with one: almost nobody breaks the HSM itself. The compromises that do happen come from the process wrapped around it - someone gets signing permissions they shouldn't have, an approval workflow gets bypassed, an admin credential leaks. The hardware will faithfully sign whatever request reaches it correctly authenticated, because distinguishing "authorized" from "should have been authorized" was never its job.
Blockchain: no institution to ask
Blockchain drops the institutional layer almost entirely. Anyone can pull the ledger and check the same cryptographic evidence everyone else is checking - no CA vouching for wallet ownership, no HSM required for consensus to work.
That transparency is the whole appeal. It's also where things get unforgiving: there's no CRL equivalent, no issuer who can invalidate a stolen key's signatures. A correctly signed transaction is valid according to protocol, whoever's holding the key that produced it.
The Ronin bridge hack in March 2022 is a useful case here, and it's more interesting than "key got stolen, funds gone." Withdrawals needed sign-off from five of nine validator nodes. Attackers - later attributed by the FBI to North Korean state actors - had compromised four validators run by Sky Mavis directly and a fifth belonging to a third-party DAO that, months earlier, had been added to an allowlist for a since-abandoned arrangement and never removed.[2] With five signatures in hand, they forged two withdrawal transactions and moved out roughly $625 million. Nobody noticed for six days - not because the chain hid anything (every transaction was sitting in plain sight on Etherscan the whole time), but because there was no mechanism watching for "this set of signatures, while individually valid, shouldn't have been possible together." The math was never the weak point. The process for deciding who was allowed to hold five keys was.
Same primitives, different bets
| System | Who anchors trust | Revocation |
|---|---|---|
| JWT / JWS | Whoever controls the JWKS endpoint | Future tokens only, by default |
| TLS / PKI | A CA hierarchy | CRL/OCSP exist, enforcement inconsistent |
| HSM | The hardware boundary itself | Fast, but depends entirely on surrounding process controls |
| Blockchain | Nobody - public verification only | Effectively none once a key is compromised |
None of these designs is wrong. JWT optimizes for operational ease. TLS optimizes for delegating identity checks at scale. HSMs optimize for keeping the key itself out of reach. Blockchain optimizes for not needing anyone's permission to verify. Each one is trading revocability for something else - speed, decentralization, simplicity - and none of them get to keep all three.
Every one of these systems also fails in the same shape: not at the signature check, but around it - in whoever runs the endpoint, whoever staffs the CA, whoever approves the signing request, whoever gets added to an allowlist and forgotten. If you're designing a new signing system, the algorithm choice is usually the easy 20%. How much revocability you're willing to give up for how much decentralization - that's the part worth spending real time on.
Sources
[1] Hoogstraaten, Hans. Black Tulip Report of the Investigation into the DigiNotar Certificate Authority Breach. 2012. https://doi.org/10.13140/2.1.2456.7364.
[2] Halborn, "Explained: The Ronin Hack (March 2022)"; The Record, "More than $625 million stolen in DeFi hack of Ronin Network," March 2022.