Course certificates and digital badges on a self-hosted platform

Why certificates and badges on your own platform need a records plan first

Organizations that sell or deliver courses need to issue credentials they can prove years later, and the platform choice between Moodle and Open edX matters less than how credential records, completion criteria and learner identity are designed. A certificate that cannot be traced back to a verified learner, a defined course version and a set of completion rules is a PDF, not evidence. Decide these three things first, then select the platform that fits your teaching model and operating team.

Moodle has the more direct badge model. It supports site badges available across the whole site and course badges limited to users enrolled in one course, and earners can push badges to a Badgr backpack. Open edX takes a different route: certificate issuance depends on how the course is configured and on add-ons, so the team must specify the template, trigger conditions and record storage rather than assume they come built in. Confirm with your partner exactly which certificate and badge features your chosen release provides and which need custom work, because that gap drives both build effort and long-term maintenance.

Whichever platform you choose, write a record model before any template is designed. Each issued credential should store the learner's verified identity from your identity provider, the course version and criteria that were met, the issuing date, the issuer, and a stable identifier that outside verifiers can check. Plan how these records will be exported and retained so they survive a platform upgrade or migration, since the badge or certificate that learners carry must still resolve after the code underneath changes. Ask your partner to demonstrate this export and a re-verification test before launch.

Which requirements shape certificate and badge design

This table maps four requirement sources (accessibility law, learner identity, branding, and record retention with migration) to what each means for badge criteria, certificate PDFs and credential pages. Read each row with your counsel and records owner, since the rules that apply depend on your organization, your learners and where they live.

Requirement source	What it means for badge criteria	What it means for certificate PDFs and credential pages
Accessibility law (ADA Title II, WCAG 2.1 AA)	Write criteria as plain-language statements that do not depend on color, images or hidden text, so screen reader users can read them. Keep badge names and descriptions text-based.	The ADA Title II rule requires state and local government web content to meet WCAG 2.1 Level AA, with compliance dates of April 26, 2027 (50,000 or more people) and April 26, 2028 (smaller entities and special districts). Credential pages need a logical heading order, alt text and keyboard access. PDFs need tagged structure and readable text layers. Confirm with counsel whether the rule applies to your credentials.
Learner identity and verification	Define who can earn each badge and how the platform confirms that learner. Course badges depend on enrolment, so the enrolment source must match your identity provider.	Certificates should show the legal name the learner verified, not a display name. Confirm which identity method your organization accepts (SSO, government login, or proctoring) and whether a learner can correct a name after issue.
Branding and issuer identity	Badge issuer name, image and description must be consistent across site and course badges so learners and employers can trace who awarded them.	Logos, signatures, colors and program names on PDFs must match your brand rules. Keep a versioned template so older certificates still show the issuer and wording they were issued under.
Record retention and evidence	Set a fixed criteria version for each badge. Changing criteria after issue can make earlier awards hard to explain, so record the version used for each earner.	Store each issued certificate with its issue date, template version, learner ID and course version. Confirm retention periods for training records with your records and legal teams, since they vary by sector and jurisdiction.
Verification and public credential pages	Criteria pages should be stable URLs that remain reachable for the period you commit to, so a verifier can read what the badge means.	Verifiable certificates need a unique link or ID that resolves to a status page. Confirm whether learners may hide or revoke credentials and how revocation is recorded.
Migration and survival of credential records	Export badge definitions, criteria and issuer data in a documented format before any upgrade or hosting change, since Moodle 5.3 and Open edX Verawood upgrades can change the environment.	Plan how issued certificate links and verification IDs will keep working after a move. Confirm with your implementation partner how the old domain or ID scheme will redirect or resolve.
Pushing badges to learner backpacks	Confirm that the backpack service you use accepts the badge format and criteria URL that your platform generates. Moodle can push badges to a Badgr backpack, so test that path before launch.	Credential links shared to external profiles should point to a page that remains available. Confirm whether learner data sent to a third-party backpack needs a notice or consent under your privacy rules.
Data location and third-party services	Keep badge issuance data in the hosting region your policies require. Avoid external services that store learner names unless your data rules allow it.	Certificate generation and PDF rendering should run inside your infrastructure if your policy requires it. Confirm where every service in the issue path stores data.

Moodle or Open edX for issuing credentials

Moodle issues Open Badges through two scopes. Site badges are available across the whole platform and suit institution-wide recognition, such as completing an onboarding path or a internal certification. Course badges are limited to users enrolled in that course, which suits a single program or cohort. Badge criteria can be built from course completion and from specific activities, so an award can require a passed quiz, a submitted assignment or a set of completed sections. Earners can push badges to their Badgr backpack, which makes the credential portable outside your platform.

Scope decisions: Decide early whether each badge is site or course scoped, because moving a badge between scopes later changes who can earn it.
Criteria design: Combine activity completion with grade thresholds where the credential must prove competence, not just attendance.
Backpack push: Learners push badges to Badgr themselves, so confirm that your badge images, issuer details and criteria text meet what your recipients expect to see.
Long-term support: Moodle 5.3 is the next long-term support release, with security support until October 1, 2029, which gives a longer runway for a credential program than a short release cycle.
Upgrade path: Sites must be on Moodle 4.4 or later to upgrade to 5.3, so plan any older installation's upgrade before badge data is at stake.

Confirm the current badge and backpack behavior against the Moodle Docs badge pages and the 5.3 release notes before you finalize the design.

Which platforms fit credential issuing and why

Certificates and badges are only as trustworthy as the platform that issues them and the records behind them. The cards below cover the platform options, the identity sources that populate learner records, the backpack destination, and the archive that must outlive a migration.

Moodle badges for site and course awards

Moodle issues site badges available across the whole site and course badges limited to learners enrolled in that course. Fit is strongest when badge criteria can be expressed through Moodle's own completion and activity rules and when one platform already runs the learning. Confirm which badge criteria your program needs, who approves badge design, and how badges are reviewed before they are awarded to learners.

Open edX certificates deployed with Tutor

Open edX issues course certificates from the LMS, and Tutor is the official Docker-based distribution the maintainers point to for production deployments. This fits organizations selling or delivering courses on Open edX that need certificates tied to course completion. Confirm the named release in use, since only the latest named release is supported, and confirm how certificate templates, signatories and branding are set and tested before each cohort.

Canvas LMS as an alternative issuer

Canvas LMS by Instructure is licensed under AGPL-3.0, so it can be self-hosted under the same copyleft obligations that apply to Open edX. Choose it when the institution already runs Canvas for academic delivery and wants one credential workflow. Confirm the badge and certificate features you need against the version you deploy, the hosting model, and whether your team can operate the stack without a vendor relationship for updates.

Identity sources that populate learner records

Credential records are only as accurate as the learner identity behind them. Moodle core supports LDAP, OAuth 2, Shibboleth and LTI authentication, and Open edX supports SAML 2.0, Shibboleth, OAuth2 providers and LTI. Confirm which identity source is the system of record for legal names, since that name appears on the certificate, and confirm how name changes and duplicate accounts are handled before anything is issued.

Backpack destinations for open badges

Earners can push Moodle badges to a Badgr backpack, which lets learners carry verifiable badges outside the issuing platform. Confirm whether your learners need a backpack at all, which backpack service they will use, and whether the issuer's identity and badge metadata display correctly there. Test the push with a sample learner account before launch, because the backpack owns the learner-facing copy once it is shared.

Migration archive for credential records

Credentials must still be verifiable after a platform upgrade, a move between hosts, or a change of LMS. Keep an exported archive of issued records, badge definitions, criteria, issuer details and verification links outside the live database, with a documented way to check each record against it. Confirm the export format, who holds the signing material, and how the archive is tested by restoring it into a separate environment before any migration is approved.

How to roll out credentials without losing records

This sequence moves certificates and badges from design to live issuance in a controlled way, so every credential issued has a defined rule behind it, a tested path to the learner, and a record that stays usable if the platform later changes.

Define criteria and branding
The program owner, academic or training lead and the brand team agree on what each badge or certificate means: the completion or assessment criteria, the issuing body name, the validity period if any, and the artwork and wording. Write these into a signed criteria document per credential, one for each site badge, course badge or certificate template. The step is done when every credential has an approver's signature and a unique identifier scheme that will not be reused.
Configure badges and certificates in staging
In a staging copy of the platform, the administrator creates site badges in Moodle or course badges in the relevant course, and sets the criteria exactly as the signed document states. For Open edX, the team configures the certificate template and the course's certificate settings in the same way. Changes are made only in staging so that the configuration can be reviewed and reproduced. The output is a configuration export or screenshot set that matches the criteria document line by line.
Test issuance with pilot learners
A small group of pilot learners, often internal staff or a friendly cohort, completes the courses through every path a real learner could take, including failed attempts, resits and manual grading. The team checks that each credential is awarded only when the criteria are met, that the wording and branding display correctly, and that the award appears in the learner's record. Any mismatch is logged, fixed in staging and retested. The output is a test log showing each scenario, the expected result and the observed result.
Verify backpack push and certificate checks
Pilot learners connect their Badgr backpack in Moodle, or use the option available in the chosen platform, and push at least one site badge and one course badge. The team confirms the badge metadata, including the criteria link and issuer, arrives intact, and that a verification page or third-party checker can read the credential. Confirm the exact verification and backpack options in your platform version before promising them to learners. The output is evidence of successful pushes and verification, kept with the test log.
Design the record export and retention
The data owner decides which fields must survive a migration: learner identifier, credential name, criteria version, issue date, issuer, expiry if any, and the verification URL or badge assertion. The team builds an export script or report, tests it on staging data, and writes a retention rule that states how long records are kept and where they are stored outside the platform. The output is a migration runbook section and a sample export file that a second person has reviewed.
Cut over to production
The team freezes the configuration, applies the same settings to production, and runs a full export before and after the change to confirm that existing credentials are unchanged. Early issuance is limited to the pilot group until the first checks pass, then opened to all learners. The migration runbook records who approved the cut over, the timestamp and the rollback steps. The step is done when the before and after exports match for all existing records and the approval is filed.
Run a post-launch check
After learners begin earning credentials, the team samples issued records against the criteria documents, checks that backpack pushes and verification still work, and confirms the export job runs on schedule. Any criteria change later creates a new criteria version rather than overwriting the old one. Schedule the check for each platform upgrade as well, since the Moodle or Open edX release in use may change the certificate or badge behavior. The output is a dated check report and an updated runbook.

Evidence that proves issued credentials are genuine

This table lists the records an auditor, customer or partner is likely to ask for when they test whether a certificate or badge is genuine, and the component that produces each one. Read each row as a question to answer before launch: if the producing component cannot show the record, the claim is hard to defend. Retention periods for every record should be set against your own records policy and confirmed with your legal and compliance team.

Evidence	What it shows	Component that produces it
Criteria definitions	The published conditions a learner had to meet for each badge or certificate, with the version in force on the issue date	Badge criteria stored with each site or course badge in Moodle, plus the course completion settings and the versioned copy you keep in your documentation archive
Issuance logs	When each credential was awarded, to which learner account, and by which rule or manual action	Moodle badge issue records and the LMS activity logs; for Open edX, certificate generation records and LMS event logs
Learner record exports	A dated copy of the learner's name, course, award date and credential identifier, reproducible on request	Scheduled export scripts or reports run against the database, stored with a hash or checksum and a run log
Verification records	Evidence that a credential can be checked against the issuer's record or a signed link, and that revoked credentials show as revoked	The verification page or endpoint, revocation entries in the credential table, and the access logs for those requests
Branding approvals	Who approved the certificate template, logo and signatory wording, and when each version went live	Change tickets or approval records in your ticketing system, plus the template version history kept in the platform or theme repository
Accessibility test results for certificate pages	Results of checks against WCAG 2.1 Level AA for the printable and web certificate views, with the date and tester	Test reports from your accessibility review, stored with the template version they tested; confirm which WCAG level your own policy requires
Migration reconciliation reports	Row counts, identifier matches and sample checks showing that every credential moved to a new platform or database still resolves	Reconciliation script output and the sign-off record kept in the archive for the migration
Backup and restore tests	Proof that credential tables and issued files can be restored and that the restored records match the originals	Backup job logs and restore test reports from the operations runbook

How credential records survive a platform migration

Issued credentials are only as portable as the platform identifiers behind them. A badge assertion or certificate record usually points to a badge or course identifier, a learner account and a verification URL on the issuing site. If you move from one Moodle version to another, or from Moodle to Open edX, those internal identifiers change, and any verification link that still points to the old site will fail or resolve to the wrong record. Before any upgrade or migration, export the issued records, map every old badge and course identifier to its new equivalent, and decide which verification address learners and employers will see after the move. Confirm with your team which identifiers appear in the certificate PDFs and badge assertions already in circulation, since those cannot be edited after issue.

Upgrade prerequisites differ by target, so confirm them before planning the cutover. For Moodle 5.1, the web server document root must point to the new public directory instead of the main Moodle folder, or the site may show directory listings or errors, so update the web server configuration as a named step. Moodle 5.3 requires sites to run Moodle 4.4 or later to upgrade, and it requires PostgreSQL 17, MySQL 8.4, MariaDB 11.4 or SQL Server 2019 or later, depending on your database. A site on an older release needs intermediate upgrades, and each of those steps has its own document root and database checks. Ask your implementation partner to list every intermediate version in the upgrade path and the database version each one requires.

Run every step in a staging environment built from a recent copy of production, including the badge images, backpack connections and certificate templates. In staging, issue a test badge and a test certificate before the upgrade, then confirm that the same credentials verify after the upgrade and after the migration to a new platform. Check the badge criteria, expiry settings and site or course scope, because a badge that loads but points to a changed course can still be wrong. Keep the original platform and its verification pages running until the mapping has been tested and signed off. Treat the staging results as the acceptance evidence for the migration plan, and write down who owns the verification address after cutover.

What buyers ask before hiring outside help

What drives the effort and cost of setting up certificates and badges?

The effort follows the number of badge types, how complex the award criteria are, and how much identity and branding work sits around them. Each badge needs its criteria written as testable conditions, such as completing graded activities above a threshold or finishing a set of course modules. Site badges and course badges are configured differently in Moodle, and Open edX certificate templates need their own design and testing. Costs split into one-time work (criteria design, templates, branding, integration with login, and test cases) and recurring work (reviewing criteria after course changes and checking credentials after each upgrade). Ask any quote to itemize these by badge type, course, and integration, and to state what testing is included.

How long does it take to launch certificates and badges?

The timeline depends on scope: how many badge types and courses are involved, whether criteria are already documented, and how much identity integration is needed. A single course with a standard completion certificate is a much smaller job than a catalog with several badge tiers, multiple audiences and a verification page. Ask for a timeline in the written scope that separates criteria sign-off, template and branding approval, test issuance, and go-live. Timelines that skip sign-off from the criteria owners usually slip, so confirm who approves each step before work starts.

What does our team need to provide before implementation starts?

Three inputs make the largest difference: named criteria owners, brand assets, and a learner data policy. Criteria owners are the people who decide what earning a badge or certificate means, such as an academic lead or a training manager. Brand assets include logos, colors, signature images, and approved wording for certificate text and badge descriptions. The learner data policy defines what personal data appears on a certificate or in a badge, how long records are kept, and whether learners may publish credentials to external backpacks. Without these, the work stops at design and cannot be tested against real requirements.

Can our in-house team build and run certificates and badges without an outside partner?

An in-house team can do this when it already runs Moodle or Open edX in production, has someone who can write and test badge criteria, and can maintain templates after each release. The harder parts are usually not the first setup but the ongoing work: keeping criteria accurate as courses change, verifying that issued credentials still display after upgrades, and handling identity and data questions. Open edX is generally run in production through a service provider or with Tutor, and the maintainers note that bare-metal installation has limited community support. Assess your team against those tasks, and decide which ones you want to keep in-house before choosing a partner.

Do platform upgrades affect credentials that were already issued?

They can, and the risk depends on how the credentials are stored, rendered and linked. Badges and certificates should be tested on a staging copy of the platform before each upgrade, including the badge image URLs, the verification pages, and the records that backpacks or employers rely on. Moodle requires sites to be on a supported version before upgrading, and release notes list changes in PHP, database and web server requirements that can affect rendering. Open edX supports only the latest named release, so older platforms must move forward on a set cadence. Ask any partner how upgrades are tested against issued credentials and what evidence it keeps.

How does identity integration change the certificate and badge work?

Identity integration affects how learner names appear on credentials and whether a badge can be tied to the correct account. Moodle core includes authentication plugins for manual accounts, LDAP, LTI, OAuth 2 and Shibboleth, and Open edX supports OAuth2 providers, SAML 2.0, Shibboleth and LTI for third-party authentication. The name printed on a certificate must come from an authoritative source, and changes to a learner's name after issue need a policy. Each identity connection adds configuration and test work, so confirm which identity providers are in scope and who owns the attribute mapping.

Does DeployOpen issue certificates or verifiable credentials?

No. DeployOpen configures and hardens the platform so that certificates and badges can be issued, verified and retained inside your own infrastructure. It prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications. Where a credential needs recognition by an accrediting body or employer, that recognition comes from the issuing organization and its external reviewers, not from the implementation work. Ask a partner to state in writing which parts of the credential process it builds and which parts remain your responsibility.

How much of the testing should the scope include before launch?

Testing should cover every badge type, each criterion path that can award it, failed and partial completions, the certificate template at each language and paper size used, and the verification and backpack push. It should also cover an upgrade rehearsal and an identity login for each audience. Ask the partner for the test cases in writing, who signs off on results, and whether test issuance uses real learner accounts or dedicated test accounts. Testing is often the line item that gets cut under time pressure, so state it as a deliverable in the fixed scope.

Questions to ask an implementation partner about credentials

Ask the partner to show, before build starts, how each badge criterion is written down and where it lives. For Moodle, that means the criteria set on each site or course badge, reviewed by the people who will award it. For Open edX, ask which certificate templates, grading thresholds and course-level settings produce a credential, and who signs off the wording. A partner who cannot show a criteria document for each credential has not yet scoped the work. Ask also how verification is tested: which URLs learners and employers will check, whether each credential has a stable identifier, and how a revoked or reissued credential is shown to a verifier.

Ask how backpack push is tested. Moodle badges can be pushed to a learner's Badgr backpack, so the test plan should include a real earner account, a badge awarded by a site badge and by a course badge, and a check that the badge image and metadata arrive intact. Ask how branding and accessibility are checked: who approves the certificate design, whether the PDF and web views meet the accessibility standards your organization has adopted, and whether a screen reader test is part of acceptance.

Ask how records are exported and mapped during migration, and whether a test migration has already restored issued credentials to a copy of the platform. Ask who owns the credential archive after launch, who holds the signing keys or hosting for verification pages, and how that ownership is written into the support agreement. Finally, ask how named releases are upgraded without breaking issued credentials. Open edX supports only the latest named release, and the next releases are Willow in December 2026 and Xylon in June 2027. Moodle 5.3 is the current long-term support release, and its upgrade path requires Moodle 4.4 or later. Ask for the partner's written upgrade test plan that compares credential URLs and records before and after each step.

Integration points and deployment pattern for credentials

A credential platform touches six systems: the identity provider, the certificate renderer, the badge store, the learner backpack, the record archive and monitoring. Each one has a deployment choice that you make inside your own cloud account, data center or air-gapped network, and each choice affects whether a credential stays valid after a upgrade or migration.

Identity provider connection

Credentials are only as trustworthy as the learner identity behind them, so the name printed on a certificate must come from a controlled source. Open edX third-party authentication supports OAuth2, SAML 2.0, Shibboleth and LTI, while Moodle core ships LDAP, OAuth 2, Shibboleth and LTI authentication plugins. Confirm which attributes, such as legal name and a stable learner identifier, your identity provider releases, and decide whether a learner can edit their name after issue.

Certificate rendering service

Certificate templates, logos, signatures and the PDF generation step are often where branding and accuracy go wrong. Decide whether rendering runs inside the LMS or as a separate service inside your network, and who owns the signing key or template version used for each issued document. Ask your partner how a template change is tested before it reaches live learners.

Badge store and issuer identity

Moodle stores site badges and course badges in the platform database, and the badge issuer identity is what a verifier checks. Keep the issuer profile, badge images and criteria under your change control, and plan the badge store as part of the platform backup set. Confirm the badge URL structure before launch, because changing it later can break links that learners have already shared.

Backpack connection

Moodle lets earners push badges to their Badgr backpack, which places the credential in a system you do not operate. Decide whether your learners are allowed to connect external backpacks, which account they use, and what personal data leaves your platform when they do. Test the push flow end to end with a sandbox learner before you promise it in course marketing.

Record archive

A credential record needs to outlive the platform release that issued it. Export learner, course, badge and certificate records to a store you control, with the issuer, criteria and version recorded alongside each credential. Ask how an archived record is verified after the source platform is retired, and who holds the retention decision.

Monitoring and upgrade checks

Issuance failures, duplicate awards and broken verification links are easy to miss until a learner complains. Monitor issuance jobs, mail delivery for certificate emails and the availability of verification URLs, and run a credential test after every platform upgrade. Moodle 5.3 requires PostgreSQL 17 and PHP 8.3 or later, so confirm that the monitoring stack and test fixtures support the versions you run.

How DeployOpen scopes and supports credential issuing

DeployOpen plans, implements, customizes, integrates, documents and supports self-hosted Moodle or Open edX inside your own infrastructure, including the certificate and badge configuration described on this page. The work runs in your cloud accounts, data center or air-gapped network, so the platform, its database and the credential records stay under your control. Most engagements are fixed-scope, and the written scope names the badge catalog, the certificate templates, the identity integrations, the branding work, the backup and migration steps for credential records and the handover. Ask any partner to list those items explicitly before work starts, because a vague scope is where badge criteria and certificate wording tend to get left out.

Ongoing support is available as a retainer, and it is the usual way to cover the recurring work that credential issuing depends on. That includes applying Moodle minor releases and the major upgrades you choose to take, checking that a new release keeps your badge and certificate settings intact, and reviewing the Moodle 5.1 document root change or the Open edX release cycle when they affect your site. Confirm with the partner how upgrade windows, emergency patching and out-of-hours response are defined in the retainer, since those terms set who acts when a credential fails to issue during a cohort launch.

DeployOpen prepares systems, controls and evidence for compliance assessments, such as configuration records, access reviews and backup test results for the credential data. It does not issue audit reports, attestations or certifications, and a credential or accreditation body that reviews your program makes its own decisions. Ask partners to confirm this boundary in writing and to tell you which evidence they will produce, in what format, and who keeps it after the engagement ends. Your legal, accreditation and program teams should define the credit and recognition rules the certificates must meet before the build starts.