Managing an Open Badge program at scale

As an Open Badge program grows, the hard part is no longer issuing — it is keeping every credential verifiable: stable hosted URLs, a working status list, keys that rotate without breaking history and a revocation process that actually runs. Periodically re-checking a sample of live badges with an independent validator catches broken keys and moved resources before your recipients do.

That is the summary. The rest of this guide is the operations manual behind it: what a live badge actually depends on, how maintenance obligations accumulate as you scale, and the small set of habits — most of them cheap — that separate programs whose badges still verify five years on from programs that quietly rot. If you are still setting up your first credentials, start with How to issue Open Badges people can trust; this article picks up where that one ends.

The day issuing stops being the job

Every badge program starts the same way: launch energy, artwork reviews, a first batch of delighted recipients. In that phase, issuing feels like the product, and the metrics that matter are counts — badges sent, recipients reached, courses covered.

Then the program succeeds, and the real job reveals itself. Because an Open Badge is not a certificate PDF that leaves your hands and becomes the recipient's problem. It is a standing, machine-checkable promise: that anyone, at any time, without asking you, can take the credential and confirm it is well-formed, correctly signed and not revoked. Your issuing pipeline runs for minutes per badge. The promise runs for years — and every badge you issue adds one more promise to the pile.

Programs fail at scale not because issuing breaks, but because nobody owns the pile.

Know your maintenance surface

Start by writing down everything a single live badge depends on. It is a longer list than most teams expect:

• The issuer profile — your identity document and the public keys verifiers fetch to check signatures. If it goes down, every badge you have ever issued fails proof verification at once.
• Criteria pages — the public description of what each badge means. Silent edits retroactively change the meaning of credentials already in circulation.
• Hosted credential JSON — the stable URLs recipients paste into CVs and LinkedIn, and that reviewers feed into a validator.
• The status list — the live revocation mechanism checked at every verification.
• Signing keys — not just the current one. Every key that has ever signed a badge must stay published, or the badges it signed stop verifying.
• Baked images — the files recipients keep. You do not host these, but you do owe recipients an original that was correct at delivery time.

This is your maintenance surface. Nothing on it is optional, and nothing on it ever shrinks on its own — a badge issued in year one depends on the same six resources in year five. The entire discipline of running a program at scale is keeping this list healthy as it multiplies.

The quiet arithmetic of scale

Here is the part that catches teams off guard. The effort to issue one more badge is flat — your pipeline does not care whether it is badge #10 or badge #10,000. But the population of credentials you must keep verifiable only ever grows:

Run the numbers for a modest program: sixty badges a month is 720 a year and over two thousand credentials in live circulation by year three. At that point, a single moved URL is not one broken badge — it is potentially hundreds of recipients whose credentials fail verification in front of exactly the people they most wanted to impress. The failure is invisible from inside your organization and painfully visible from outside it: to a verifier, an unreachable key endpoint looks the same as fraud.

This asymmetry is why mature programs stop measuring themselves by badges issued and start measuring by badges that still verify. The first number flatters you. The second one is the truth.

URLs are forever

Nearly everything on the maintenance surface is, at bottom, a URL — and the oldest advice on the web applies with unusual force: cool URIs don't change. In a credentialing context, they cannot.

A few policies make this tractable:

• Design URL schemes before scale arrives. Changing from /badges/123 to /credentials/abc in year two means redirects forever or breakage forever. Pick identifiers you can live with and freeze the scheme.
• Never let marketing own credential domains. Website rebrands are routine; a rebrand that renames badges.example.edu orphans every credential pointing at it. Keep credential infrastructure on a domain with its own governance — and auto-renew it for the longest term the registrar allows.
• Redirects are a patch, not a policy. They help in emergencies, but every redirect is one more thing that can silently break, and strict verifiers may not follow long chains.
• Audit outbound references too. Criteria pages that link to course catalogs, evidence URLs pointing at project portfolios — link rot in the resources around the credential erodes trust almost as fast as broken keys.

The test is simple: could you hand your URL list to a stranger and promise, in writing, that every address will resolve in 2035? If a URL would make you hesitate, it should not be inside a credential.

Revocation as routine, not crisis

Small programs think of revocation as an emergency lever. At scale, it is a routine operation — certification cycles end, badges get issued in error, policies change — and it needs to work like one:

Open Badges 3.0 handles status through mechanisms like the Bitstring Status List: every credential references a position in a hosted list, and verifiers check it live on each verification. Your operational duties around it:

1. Include credentialStatus in every badge from day one. Status cannot be retrofitted onto credentials already issued; a badge without a status entry can never be revoked, only disowned.
2. Write the policy before the first contentious case. Who can request revocation, who decides, on what grounds, within what timeframe, and how the recipient is informed. Deciding this during a dispute is how programs end up in the news.
3. Make the update path boring. Flipping a status bit should be a logged, reviewed, two-person operation that deploys in minutes — not a database hotfix performed by whoever still has access.
4. Keep an audit trail. At scale you will eventually be asked — by an auditor, a lawyer or a journalist — why a specific credential was revoked and when. The answer should be a lookup, not an archaeology project.

And test it: revoke a sacrificial badge once a quarter and confirm it fails verification the way it should. A revoked credential that still verifies is a far worse failure than a valid one that doesn't.

Rotate keys without breaking history

Signing keys age: algorithms get deprecated, staff with access leave, compliance regimes demand rotation. The mistake that destroys programs is treating rotation as replacement.

The rule is additive: new keys get added to the issuer profile and start signing new badges; old keys stop signing but remain published, because every badge they ever signed will verify against them for the rest of its life. Unpublishing a key is the single most destructive routine mistake in badge operations — it invalidates an entire era of your program in one deploy, and from the outside it is indistinguishable from the badges having been forged all along.

Alongside the additive rule: store private keys in an HSM or managed KMS rather than on laptops, restrict and log who can trigger signing, and write a compromise playbook now — which credentials were signed by the affected key, how you revoke and reissue them, and how you communicate it. A key compromise with a playbook is a bad week. Without one, it is the end of the program's credibility.

Monitor, sample, re-validate

Everything above fails silently. Verifiers do not email you when your key URL 404s — they just conclude the badge is bad and move on. The only way to know your promises still hold is to check them yourself, on a schedule, the same way a stranger would:

A cadence that works for most programs:

• Weekly — uptime. Automated checks on the issuer profile, every published key URL and the status list. These endpoints going down is a sev-1 incident, not a ticket; wire the alerts accordingly.
• Monthly — sampling. Pull a random sample of live badges and run each through an independent validator, reading the full report of structure, proof and status checks. Randomness matters: always testing last week's badges tells you the pipeline works today, not that year-one credentials survived your infrastructure changes.
• Quarterly — end to end. Take one badge from every issuing batch and verify it exactly as an outsider would: from the baked file in the original recipient email, on tooling you do not operate. This catches the drift that internal checks miss — expired TLS certificates, contexts that no longer resolve, a CDN rule quietly stripping JSON content types.

When a sampled badge fails, treat it as representative, not exceptional. One badge with a broken key URL usually means every badge from that signing era shares the problem.

The human layer

Infrastructure keeps badges verifiable. People keep infrastructure alive — and at scale, the human layer fails more often than the technical one. Programs do not usually die of cryptography; they die of the one person who understood the setup leaving the organization.

The runbook every scaled program needs on paper:

1. A named owner — a person, with the program in their job description, not a shared inbox that everyone assumes someone else reads.
2. Monitored endpoints with real alerts that page someone who can act, not a dashboard nobody opens.
3. A written, rehearsed revocation policy — including who holds authority when the owner is on leave.
4. A standing re-validation schedule with its findings logged, so trends are visible before they become incidents.
5. A migration plan for the scenario every program eventually faces: changing platforms or vendors without breaking a single existing URL, key or status reference. If your current setup cannot be migrated away from gracefully, that is worth knowing before you are forced to find out.

The test for all five is the same: could a competent stranger, armed only with your documentation, run the program next month? If not, your program has a single point of failure with a human name.

Scaling in-house vs. on a platform

Everything in this article can be run in-house, and technically strong teams do. But be honest about what you are signing up for: uptime obligations on a half-dozen endpoint classes, key ceremonies, status infrastructure, audit trails and a succession plan — forever, because the badges do not expire just because the project budget did.

Dedicated credentialing platforms such as Certifier exist to absorb exactly this operational load: hosting, signing, key management, status lists and delivery, maintained as their core business rather than your side project. The evaluation method is the same one this site always recommends — ignore the marketing and test the output. Issue a sample badge, run it through an independent validator, revoke it, and run it again. A platform whose credentials pass on neutral tooling, and fail correctly after revocation, is doing the job. Then ask the scale-specific questions: what happens to your URLs if you leave, who owns the signing keys, and can you export every credential in standard Open Badges 3.0 form?

Whichever way you go, accountability is not outsourceable. The platform maintains infrastructure; the promises still have your name on them.

A program is a promise with a maintenance schedule

Managing an Open Badge program at scale is not glamorous work. It is URL discipline, monitoring dashboards, key ceremonies and runbooks — the same unglamorous machinery behind anything on the internet that strangers are expected to trust.

But the payoff compounds exactly the way the obligations do. Every year your badges keep verifying — through independent checks, on neutral ground, without your involvement — your program's signature becomes worth more. Issuers who treat maintenance as the product end up with something rare: credentials that are trusted because they have a track record, not merely a design. The pile of promises becomes the asset. Keep every one of them.