Open Badge security basics
What actually protects an Open Badge — cryptographic proofs, issuer keys and status lists — and why a screenshot proves nothing.
OPEN BADGE VALIDATOR · Oct 14, 2026
What protects an Open Badge is not the image but the cryptography: a signed credential, the issuer's published keys and a status list that can mark it revoked or expired. A screenshot can be copied by anyone, which is why a quick check in the Open Badge validator — not a glance at the artwork — is the honest way to confirm a badge.
This article is the plain-language version of how that protection works. No prior cryptography knowledge is assumed — just a tolerance for the occasional key metaphor. By the end you'll know what actually secures a badge, which attacks the design defeats automatically, which judgment calls remain yours, and what the everyday security baseline looks like for issuers, recipients and verifiers alike.
The artwork is not the security
Start with the hardest habit to unlearn. For a century, physical credentials were secured by making them hard to reproduce: embossed seals, watermarks, special paper. Our instincts still assume that looking official correlates with being genuine. In the digital world, that correlation is exactly zero.
Fig. 1 — Two layers, only one of them secure. The artwork is decoration; the signed data is the credential.
Any image can be copied pixel-for-pixel, edited in minutes or generated from scratch. A forged badge image is indistinguishable from a real one, because the image was never the secure part. As What is an Open Badge? explains, a real Open Badge is a two-layer object: the visible image, and a machine-readable credential — since Open Badges 3.0, a W3C Verifiable Credential — either embedded inside the image file ("baked") or hosted at a URL. All of the security lives in that second layer.
The practical consequence is blunt: a badge that exists only as pixels is not evidence of anything. Not because the person showing it is lying, but because there is nothing to check. Security analysis of an Open Badge begins where the artwork ends.
A signature in plain language
The heart of Open Badge security is public-key cryptography, and the core idea fits in a paragraph.
The issuer owns a key pair: a private key and a public key, mathematically linked. When a badge is issued, the issuer computes a signature over the credential's exact contents using the private key — which never leaves their systems. The matching public key is published at a stable URL in the issuer's profile, where anyone can fetch it. Verification runs the math in reverse: given the credential, the signature and the public key, the check passes only if the signature was produced by the matching private key and the content is byte-for-byte unchanged.
Fig. 2 — One key signs in private, the other proves in public. Verification needs no secrets and no permission.
Two properties fall out of this design, and they are the reason the whole ecosystem works:
- Authenticity. Only the holder of the private key could have produced the signature. If the signature validates against the issuer's published key, the issuer signed it.
- Integrity. The signature covers the entire credential. Any modification after signing — any at all — breaks the math.
Notice what is not required: a central registry, an account on the issuing platform, a verification fee, or the issuer even being online at the moment of checking (for signed credentials). The verifier needs the credential, the public key and arithmetic. That independence is the design goal of the entire verifiable credentials model.
Tamper evidence: why one character matters
"Any modification breaks the math" sounds like marketing until you watch it happen. Here is the scenario that makes it concrete.
Fig. 3 — Tamper evidence in practice. One appended word, and the proof no longer verifies. There is no partial credit.
Someone receives a genuine badge for "Data Analysis" and decides their résumé would look better with "Data Analysis PRO". They open the JSON, append one word, and present the result. Every other byte is authentic — the issuer, the dates, the signature itself. It doesn't matter. The signature was computed over the original contents; the verifier recomputes over the edited contents; the values don't match; the proof check fails. The tampering isn't detected by a human noticing something odd — it's detected by arithmetic that cannot be negotiated with.
This is the property security people call tamper evidence, and it's worth internalizing its shape: the credential doesn't prevent editing (nothing can stop someone changing a file on their own laptop), it makes editing self-defeating. The altered file is worthless everywhere a verification check runs. Which is also why the single most effective security measure any organization can adopt costs nothing: actually run the check, every time, as described in How to verify an Open Badge.
The threat model: four classic attacks
Security thinking starts with the question what would an attacker actually try? For Open Badges, four attacks cover most of the territory — and the standard was designed with each of them in mind.
Fig. 4 — Four classic attacks, four built-in answers. All four defences run automatically in a single validator pass.
- The screenshot forgery. Fabricate or beautify a badge image. Defence: verification operates on data, never pixels. A forgery has no credential behind it, so there is nothing that can pass. The attack only works on people who verify with their eyes.
- The edited credential. Take a real credential and improve its contents. Defence: tamper evidence, as above. The proof check fails deterministically.
- The fake issuer. Create a credential signed with your own key, claiming to be "Example University" — the signature will be genuine, just not theirs. Defence: the proof binds the credential to a key, and the key to a URL. A verifier sees which domain published the key.
badges.example.eduversusexample-university-badges.xyzis a judgment call the verifier must make — this is the one place where cryptography hands the problem back to humans, and it deserves the three seconds it takes. - The stale badge. Present a credential that was genuine but has since been revoked or has expired. Defence: live status checking, covered next.
Note the pattern: three of the four attacks are defeated entirely by machinery, and the fourth (issuer identity) is reduced to a single, well-framed human question. That's a good trade — most credential systems in history left all four questions to humans.
Issuer-side security: keys are the crown jewels
Everything above assumes the issuer's private key is actually private. For issuing organizations, that assumption is the security program. Two failure modes matter, and they fail in opposite directions:
- A leaked private key signs lies. Anyone holding it can mint credentials indistinguishable from real ones, backdated at will. Every badge ever signed with that key becomes suspect.
- A dead public key URL kills truths. If the issuer profile or key document stops resolving, perfectly genuine badges become unverifiable — indistinguishable, from the outside, from fakes.
Fig. 5 — Key hygiene for issuers. A leaked key signs lies; a dead URL kills truths. Both are preventable with habits.
The hygiene list is short and unglamorous: keep the private key in a proper secret store (never in repositories, laptops or inboxes); publish public keys at one stable HTTPS URL and treat that URL as a production dependency; rotate keys on a calendar rather than after an incident; keep old public keys resolvable so historical badges stay verifiable; and monitor the issuer profile with the same alerting you'd give a customer-facing service.
If that sounds like operational work your team doesn't want to own — that's a legitimate conclusion, and it's why most organizations issue through a managed platform. Services like Certifier handle key custody, signing and hosted verification infrastructure as their core business, which for a typical L&D or certification team is both more secure and dramatically cheaper than building the same discipline in-house. Whichever route you choose, the obligations themselves don't disappear; the long-term versions of them are catalogued in Managing an Open Badge program at scale, and the initial setup in How to issue Open Badges.
Security after issuance: revocation and expiry
A signature proves what was true at the moment of signing. Security, however, continues after issuance: certifications expire, badges get issued by mistake, and occasionally one must be withdrawn for cause. The standard's answer is the status list.
Fig. 6 — Security after issuance. One bit per badge, flipped by the issuer, readable by everyone — checked live at every verification.
Mechanically, it's elegant: the issuer hosts a long bitstring — the Bitstring Status List — where each issued credential owns one position. 0 means active; 1 means revoked. A verifier fetches the list and reads one bit. Because the list contains millions of positions and the lookup happens on the verifier's side, the issuer never learns which badge was checked — revocation checking without surveillance.
Expiry works even more simply: credentials can carry validFrom and validUntil dates, compared against the clock at verification time. An expired first-aid badge failing its status check is the system working.
The practical takeaway for anyone relying on badges: verify at the moment of the decision, not once and forever. A badge is a live claim, not a laminated card; a report from last quarter says nothing about today.
What verification can — and cannot — tell you
Honest security writing includes the limits. A full validator pass proves that the credential is structurally valid, signed by the holder of a specific key, unchanged since signing, unrevoked and within its validity window. That is a lot. It is not everything:
- It doesn't prove the issuer is reputable. Cryptography confirms who signed, not whether they should be believed. Judging the issuing organization — its domain, its reputation, its assessment standards — remains your call.
- It doesn't prove the achievement is rigorous. A validly signed badge for a trivial quiz verifies perfectly. Read the criteria.
- It doesn't prove the person showing the badge earned it, unless you also match the credential subject's identity to the person in front of you.
A useful mental model: verification removes the forgery questions from the table so your attention can go to the judgment questions, where it belongs. Machines handle math; you handle meaning.
The everyday security baseline
Open Badge security ultimately isn't a feature you buy — it's a small set of habits, practiced consistently by everyone in the chain.
Fig. 7 — The everyday baseline. Five habits that cost seconds and close almost every practical attack.
- Share and request links or original files, never screenshots. Pixels can't be verified; baked files and hosted URLs can.
- Run every badge that matters through an independent validator. It takes seconds, needs no account and stores nothing.
- Read the full report, not just the summary color. A failed status check and a failed proof check tell very different stories — the verification guide explains how to read each line, and how it works shows what runs underneath.
- Treat dead issuer URLs as unverifiable, not as valid. Absence of evidence is not a pass.
- Re-verify at decision time. Revocation and expiry are live states; check them when the stakes are live too.
None of this requires expertise, budget or ceremony. That is the quiet achievement of the Open Badges design: it moved credential security from "trust the seal and hope" to a ten-second check anyone can run. The cryptography does the heavy lifting. All it asks of us is the habit of actually looking.