Platforms for issuing Open Badges 3.0: how to choose and test one

You are choosing an issuing platform for 8,000 course completers. A demo shows attractive badges, a recipient portal, and a sharing button. Before you sign, ask one person outside the vendor's environment to verify an original export, revoke a disposable badge, and download a recipient's file. Those three tests expose problems that a polished demo cannot.

This is a shortlist of platforms to investigate, followed by an evaluation you can run in a week. It is not a certification list. Vendor capabilities change by product, plan and rollout date. Inclusion here does not establish that every account issues conformant Open Badges 3.0. Check the exact product and version in the 1EdTech certified product directory, then test the actual output you would give your recipients.

First separate four different claims

A vendor might say it issues "digital badges," supports "verifiable credentials," produces "Open Badges 3.0," or has a "certified" product. These statements answer different questions. A hosted page with an image is a digital badge in everyday language. A verifiable credential may follow a W3C data model without satisfying Open Badges 3.0 achievement rules. A product's 1EdTech certification has a named specification and version; it does not certify every future feature, subscription tier or sample credential.

Write down the product name shown in the directory, the specific certification entry, and the date you checked it. As of October 2026, the Open Badges 3.0 specification page identifies a Final Release document revision 1.4.5, issued 29 June 2026. That document revision is distinct from the badge format version and from a VC 1.1 or 2.0 profile. If a vendor says "version 1.4.5 compatible," ask which sample credential and tests support the statement. If there is no directory entry, ask whether the vendor intends to pursue certification and what their conformance test evidence covers. Absence is a procurement fact; it does not automatically mean every badge they produce is invalid. An export test and a certification check complement each other: one evaluates a file, the other evaluates a named implementation against a programme of tests.

Specify the evidence you need from each vendor

Be precise about scope in the request for proposal: "Our institution needs to issue an Open Badges 3.0 credential that recipients can download and an independent 3.0 verifier can check." Add which proof mechanism, underlying VC profile, and status behaviour you need once you have tested candidate samples. Do not accept a screenshot of a vendor-hosted verification page as the sample.

An evaluation shortlist, with questions worth asking

The following are issuing or credential-management products to investigate, not a ranking of certified 3.0 implementations. Ask each supplier to demonstrate your required specification and plan. There is no reason to assume a feature visible on one product's sales site is available to every tenant.

Platforms to put through the same tests

• Accredible may suit a large certificate or professional-education programme. Ask for a recipient-downloaded 3.0 credential and a demonstration of expiry or renewal.
• Canvas Credentials may fit an existing Canvas workflow. Ask whether this deployment issues 3.0 or whether some awards remain 2.x.
• Credly is worth evaluating for employer-facing badge sharing. Ask whether recipients on your proposed plan can export the original interoperable credential.
• Open Badge Factory is relevant to programmes managing badge definitions and recipient sharing. Request a legacy 2.x assertion and a newly issued 3.0 export separately.
• BCdiploma may be relevant when you also deliver diplomas. Ask which proof and status mechanism is present in the downloaded badge.
• Sertifier is worth testing for training-provider distribution. Validate a bulk-issued export and a disposable badge withdrawn after an error.
• Certopus may fit course or event delivery. Ask whether a recipient can download the original after leaving the organiser's mailing list.
• Virtualbadge.io may fit a small-course or event programme. Test whether its offered export contains the credential or only a shareable preview.
• SmartCertificate is worth evaluating for document delivery alongside badges. Ask what survives when the hosted recipient page or contract ends.

Treat legacy Badgr awards separately

Badgr (now under Parchment Digital Badges) deserves separate attention if you have a historical installed base. It is associated with the older 2.0 ecosystem; badgecheck.io is explicitly a 2.0 validator. Verify which product and format is in front of you rather than treating the Badgr name or Canvas integration as proof of a particular output version. If your programme includes both old and new cohorts, ask for a representative sample of each.

For any vendor missing from this list, use the same tests. Open Badges is intended to make the resulting credential interoperable; the right procurement method should work for a new supplier as well as an established one.

Run a sample-credential test before any design workshop

Send vendors a small specification: an achievement with a name, issuer-owned stable ID, criteria, a recipient identifier, issue date, and optional evidence that does not expose personal work publicly. Ask them to issue it using the same flow and plan you would buy. Require the recipient to download the badge through the recipient interface, not an administrator-only export or a specially prepared sample from sales.

Use an independent Open Badges 3.0 validator and save the per-check report. Note the detected profile and proof type, not just a top-level verdict. Check that the credential's issuer and achievement identifiers match the organisation and programme you intend to run. Open the criteria and confirm a person outside the programme can explain what was assessed. If it is a baked PNG or SVG, upload that downloaded image itself; an image preview can lose its embedded data when copied through social media.

Try a second sample with one deliberate failure under vendor supervision: revoke a disposable badge using the platform's documented workflow and check whether an independent verifier observes the withdrawal. If revocation is not offered, require a written policy for issuance errors and reissue. Do not assume every product implements a particular status list, or that a green proof result means a status source was checked.

Ask the vendor to explain the input if your verifier cannot process it. "Our dashboard displays the badge" does not answer whether the original export is signed, whether your chosen cryptographic suite is supported, or whether the credential is 3.0. An unsupported proof is different from a proof that was actually checked and failed. Keep the original file for a second verifier or standards review.

Integration: follow a recipient through the whole lifecycle

Procurement teams often focus on an API's "issue credential" call. Recipients experience a longer sequence: enrolment, assessment, approval, delivery, account recovery, export, sharing, and possible renewal or correction. Build a test with a student who changes email address after graduating. Can they still access the original credential? Does your organisation keep a safe, auditable route to correct a mistaken award without silently changing an existing signed file?

For a learning-platform integration, map each field rather than relying on a generic "LMS integration" label. Where does the achievement name come from? Who approves criteria changes? Does the badge issue immediately on course completion or after assessment moderation? If the assessment is withdrawn, is the recipient notified and does the status change? Decide which system owns the assessment decision, credential creation, recipient consent, and support requests. A webhook saying "completed" does not prove the learner met a practical rubric.

Test volume using a non-production cohort. Issue, export and verify multiple credentials from the same batch. Look for mistaken subject IDs, duplicated badge IDs, missed deliveries, and renewal dates derived from the wrong time zone. Keep test subjects and evidence fictional, and remove test credentials from any public directory when finished.

Key hosting is a portability requirement

A credential's signature depends on the verification method named by its proof or token. Ask the vendor to show the actual public-key resolution path from your downloaded sample. Is the issuer identifier on your domain or the vendor's? Who can change the key document? What happens to badges signed with last year's key when you rotate to a new one? A current key cannot silently validate a badge that explicitly names a retired method.

Write these answers into the contract or operational runbook. You want a named owner for the issuer domain, public key hosting and old-key retention; an incident procedure for a compromised signing key; and a test credential signed by each retained method. If the vendor manages keys, ask what they export on termination, what they keep serving for past credentials, and how they notify you about a compromise. A downloadable PNG is useful, but portability fails if the key it refers to disappears next quarter.

Key security is not just a promise to "use encryption." Ask who can trigger issuance, how administrators are reviewed, whether a compromised tenant can mint badges for another tenant, and how the vendor records approvals. For regulated or high-impact awards, separate permission to design a badge from permission to issue it and from permission to revoke it.

Status and evidence: test your failure cases

Revocation, suspension and expiry have different meanings. A wrong-person issuance may need revocation; a temporary loss of eligibility might need suspension if supported; an expiring safety authorisation should have a documented renewal path. Ask for a disposable sample of each state the product claims to support. Validate it outside the vendor dashboard and record the time the changed state became visible.

If status checks rely on a public endpoint, ask who maintains its availability after your contract ends. An unavailable status list is not equivalent to a clear one. The vendor may also offer a private support workflow for checking whether an award was issued in error. Decide ahead of time whether such a workflow is sufficient for your use case, and tell relying parties how to use it. Never advertise instant global revocation unless your actual exported credential and verifier demonstrate it.

Evidence deserves a privacy review. A badge can say that a learner passed a lab assessment without publishing their graded work or health information. Test who can access evidence URLs after the learner leaves, whether access requires authentication, and whether recipients can see what they share. For an external verifier, "evidence unavailable to this reader" is a useful, honest result. Public access is not the default requirement for a credible assessment.

Plan the exit before the first cohort

Ask for a written exit pack, then run an exit drill on sample data. The pack should include original issued credentials, badge-definition IDs and criteria, the mapping needed for recipient support, key and issuer identifiers, status-service ownership, and a plan for recipient access. Agree which public URLs your institution will maintain. Avoid accepting only a CSV containing image URLs: it does not replace the signed files or keep verification methods alive.

Temporarily log out of the issuing console and ask an unrelated colleague to verify a previously issued file. Test both a newly signed badge and an old-key sample. If status is supported, verify a revoked test credential too. Record every request that goes to a vendor-controlled domain. These are the dependencies you must transfer, keep under contract, or document as risks. For the full operational version, see making skills recognition portable.

A platform may also host share pages that recipients have posted to professional profiles. If the pages vanish, the underlying signed files may still be valid, but holders lose convenient links. Decide whether you can redirect URLs or provide a new recipient page. Notify people before moving endpoints; they should not discover a broken profile link during a job application.

A one-week decision procedure

Day 1: confirm your claim: what did the learner do, what criteria apply, who is authorised to issue it, and whether you need live withdrawal. Request samples and the named 1EdTech certification entries. Days 2–3: have recipients download and independently validate files from each vendor. Record format, underlying profile, proof, key host and status outcome. Day 4: run a revoked-sample check and an email-change or account-exit test. Day 5: compare vendors on assessment workflow, recipient support, operational ownership and annual exit risk, not on badge artwork alone.

Make the comparison reproducible: keep the exact sample files, report dates, directory URLs, and a brief explanation of every failure. Avoid emailing real student credentials to all bidders. Use test recipients and fictional evidence. If one supplier cannot demonstrate a required property on the offered plan, describe the missing evidence clearly rather than guessing at their roadmap.

For older programmes, begin with Open Badges 2.0 platforms and migration; a sensible dual-version transition may be better than reissuing everyone immediately. For a technical explanation of the badge and VC relationship, read how Open Badges fit into verifiable credentials. The 1EdTech certification process and certified product directory are the references to consult again when the contract is ready to sign.