Moodle Open Badges 3.0: what issuing verifiable badges changes for your courses
Moodle Open Badges 3.0 lets an institution issue badges from Moodle under the Open Badges 3.0 standard, which Moodle added in version 4.5. A learner can then hold a credential that others can verify and show outside the LMS, such as on a professional profile or in another organization's system. Teams need this when a course result should travel with the learner, for example a microcredential, a professional development record or a skills statement that an employer or another school must be able to check without logging in to your site. It is a Moodle core feature, so there is no plugin to install. It is configured as a project, and the badge design work (what each badge means, who earns it and how it is evidenced) matters more than the switch itself.
Once badges are issued under this standard, each one carries structured information about the learner's achievement and the issuer, so the badge is more than an image shown on a Moodle page. For course teams, the question shifts from whether the learner passed to exactly what the badge asserts. Settle the name, description, criteria and evidence wording before anyone configures the badge, because those fields are shared with every learner who earns it. Ask your platform owner which fields can still be edited after the first badge is issued, and what an edit does to badges already in learners' hands.
Badge criteria decide who earns a badge and when. In Moodle, criteria can depend on activity completion within one course, and cross-course badges combine conditions from several courses, which is the usual route for program-level credentials. Map each badge to a short list of completion conditions and write those conditions in plain language, so course authors and the badge owner read them the same way. Before you publish, test the logic with test learner accounts, including one that meets every condition except the last. Partial progress is a useful edge case, because it shows whether the criteria award only when they should.
Every badge needs a named owner. Someone must approve the wording, decide what happens when course content changes after learners have earned the badge, and set who can revoke or reissue it. Course authors know the content, but the registrar, quality office or program lead should sign off the claim the badge makes. Ask your platform owner to confirm which Moodle roles can create, edit and issue badges at site level and at course level, and test those permissions with a non-administrator account before the rollout.
Learners share badges from their own profile, and the people checking them depend on the badge data remaining available at the issuer's address. Plan where that data is hosted, how it is backed up with the rest of the site and what happens if the site's address changes during a migration or upgrade. If you run Moodle 4.5, confirm its security support end date and your upgrade path before committing to a badge program that must run for several years. Check the exact verification behavior and hosting requirements in the Moodle documentation for your version, and test a shared badge end to end in a staging site first.
Configuration options for Moodle Open Badges 3.0 and when each fits
This table compares the main configuration decisions for badges issued under Open Badges 3.0 in Moodle, with the situation where each option fits. Read each row as a question to settle before building badges, then confirm the exact settings in the Moodle 4.5 or later documentation for your version. The main takeaway is that criteria, scope and sharing choices are hard to change once learners have earned badges.
| Decision | When the option fits | What to confirm in your Moodle version |
|---|---|---|
| Activity completion criteria | Achievement is proven by finishing specific graded or tracked activities in one course. | Which activity types can serve as criteria, and how completion must be tracked for them to count. |
| Course completion criteria | The badge represents finishing an entire course and its overall completion rules. | How course completion conditions are set, and whether they must be enabled before badges can use them. |
| Manual award | Evidence sits outside Moodle, such as a workshop attendance record or an assessor's sign-off. | Who holds the award permission, and whether awards can be revoked or reissued. |
| Site-level badges | The credential applies across many courses or the whole institution, such as a staff induction badge. | Which roles can create site badges, and where learners see badges earned at site level. |
| Course-level badges | The credential belongs to one course team and should stay under that team's control. | Which course roles can create, edit and award course badges, and how they are listed. |
| Cross-course badges | Achievement spans several courses, such as a programme or competency pathway. | Whether the criteria can combine completions from multiple courses, and how the criteria are structured. |
| Expiry and validity | The credential should reflect current skills, such as safety or licensing training that needs renewal. | Whether expiry is set per badge, how expired badges display, and how renewal is handled. |
| Badge image and description | Learners and external viewers need to understand what the badge proves, and recognition depends on the visual design. | Accepted image formats and sizes, and which description fields are published with the badge. |
| Learner sharing path | Learners will present badges to employers, regulators or other institutions outside your site. | How learners share or export badges, what data travels with them, and what they can control. |
How Moodle issues Open Badges 3.0 credentials to learners
Moodle issues an Open Badges 3.0 credential in three steps. First, a site administrator or course manager defines a badge and attaches criteria to it, such as completing a set of activities, reaching a grade, or meeting a course completion condition. Second, Moodle evaluates those criteria against the learner records it already holds. Third, when a learner meets the criteria, Moodle creates an award for that learner and that badge, and the award carries the badge metadata that a verifier later reads. The exact criteria types, and whether awards can also be issued manually in your version, should be confirmed in the Moodle 4.5 or later documentation for your site. Plan the criteria around the completion settings you already use, because a badge is only as reliable as the records behind it.
The badge definition and the issued award are separate objects, and the difference matters for change control. The definition is the template: its name, description, image, criteria and issuer details. The award is the record of one learner receiving that badge at one point in time. Moodle keeps awards when a course or activity is later edited, so a change to the definition is not a neutral edit once awards exist. Confirm in the Moodle documentation which definition fields are copied into each award at issue time and which are read from the live badge record when a credential is viewed or verified. That answer determines whether a wording fix can reach credentials learners already hold, and which fixes instead require a replacement badge.
The issuer identity and the badge metadata must be settled before the first award. The issuer describes the organization vouching for the credential, typically through a name, a web address and a contact point. Badge metadata covers the name, description, image, criteria link and any alignment information you choose to publish. Learners and employers will carry these values into digital wallets and job applications, so they become part of the permanent record. If the organization changes its legal name, moves to a new domain, or replaces the badge image after awards exist, issued credentials can point to details that no longer match. Decide who owns the issuer profile, agree the wording with communications and legal teams, and freeze the values before the first live issue.
Before going live, run a controlled test. Create a staging copy of the site or a test course, define one badge with the exact criteria you plan to use, and award it to a test account. Then inspect the credential that Moodle produces, check that the issuer and badge fields show the values you approved, and confirm that any URLs in the payload resolve. Also confirm how credential identifiers are built, since they may depend on the site's web address. That dependency matters if the site moves to a new domain or is rebuilt during a platform upgrade. Record the results as an acceptance check, and keep a change log for every later edit to an issuer or badge definition so support staff can explain exactly what each learner holds.
How to set up Open Badges 3.0 in Moodle, step by step
This sequence takes a Moodle site from a version and server check to badges that learners can share outside the institution. Each step closes with a check the institution can record before learners see anything.
Confirm the Moodle version and upgrade path
Confirm the site runs Moodle 4.5 or later, the first release with Open Badges 3.0 support, and that it is on a supported release. If you plan to move to a newer version, check the target's requirements in the Moodle 5.1 and 5.3 release notes: 64-bit PHP, the supported database version and, from Moodle 5.1, a web server document root pointed at the new /public directory. Confirm the site meets the stated minimum version to upgrade (4.2.3 for 5.1, 4.4 for 5.3). Done when a written checklist marks each requirement as met and your platform team has signed off the upgrade path.
Agree issuer and badge design standards
Meet with the institution's academic, communications and brand owners to agree who appears as the issuer, the issuer URL and contact details, and the badge image standards, including size, format and naming. Confirm who may approve new badges and who owns the record if a learner queries an award. Ask the institution to confirm the wording learners will see on shared badges. Done when the agreed standards are written down and each badge owner is named.
Enable badges and Open Badges 3.0 issuing
In a staging copy of the site, enable badges in the site settings and turn on the Open Badges 3.0 options in the badge settings, following the documentation for your exact Moodle version. Enter the issuer details agreed in the previous step and test that the site's public address is correct, because shared badges link back to it. Done when the badge settings show the Open Badges 3.0 issuer information you entered, and a saved test badge displays the agreed image and name.
Create a pilot badge with simple criteria
Create one pilot badge in a single course with simple, objective criteria, such as completing one named activity or achieving a set grade on one graded item. Avoid combining course, time and activity conditions in the pilot, so that any fault is easy to trace. Set the badge to active only after reviewing the description, image and criteria text. Done when the pilot badge is saved, its criteria match the wording agreed with the institution, and the course owner has reviewed it.
Award a test badge to a test account
Create a dedicated test learner account, enrol it in the pilot course and complete the criteria as a learner would. Confirm the badge is awarded automatically if the criteria are automatic, or manually award it if the criteria require a teacher. Check that the award appears in the test account's badge list with the correct issuer and date. Done when the award is recorded against the test account and the issuing record matches the criteria you set.
Verify learners can view and share awards
Sign in as the test learner and confirm the badge can be viewed from the profile and the award page. Then follow the sharing option and check that the shared badge opens outside the site, shows the issuer and criteria, and links back to the verified record. Test sharing from a browser where you are not signed in. Done when the test learner can view and share the badge, and the verification page loads without signing in.
Roll out badges to courses in stages
Add further badges course by course, starting with the courses whose owners agreed to participate in the pilot. Use the same design standards and criteria checks for each badge, and record the badge owner and the criteria in your own register. Review the first real awards with the course owner before expanding to the next group of courses. Done when each course's badges are listed in the register, every badge has an approved owner, and the institution has signed off the wider rollout.
Designing cross-course badges that reflect a learning pathway
A cross-course badge is only as credible as the pathway behind it. Before building criteria, the team needs agreed answers on which courses count, which activities produce completion data, and who signs off when several course teams contribute.
Selecting the courses that count
Start with a written list of the courses in the pathway, their order and the minimum they must contribute. Decide whether every course is required or whether learners choose from a set. Confirm that each course exists as a single Moodle course with a stable course ID, because badge criteria point at courses, and a course copied for a new term can break the link to the original. Record which courses are retired or replaced so old awards still map to a valid pathway.
Mapping activities to completion data
A cross-course criterion can only rely on data Moodle records. Identify which activities carry completion tracking, such as quizzes with a passing grade, assignments with grading, or activities set to completion on view. Check each one in the course settings before writing criteria. Activities that depend on a manual teacher mark need a process for when the mark is entered, because the badge will wait for that record.
Keeping criteria consistent across courses
When two course teams define success differently, the badge becomes hard to explain. Agree on common definitions for pass marks, grade scales, attempt rules and completion conditions, and write them down as a shared standard. Compare the criteria options available in the Moodle version you run, since the set of cross-course conditions can differ between releases. Confirm this against your own site before finalizing the design.
Handling learners who join mid-pathway
Learners often start at course three or enrol after the first cohort has finished. Decide whether earlier courses completed outside the pathway count, whether prior results can be imported, and how the badge reports progress for someone who has not started. Test the enrolment and completion paths with a learner account that joins late, because a criterion that only checks course completion may never trigger for a learner who skipped an optional step.
Governing changes to the pathway
Each course team edits its own content, so a change in one course can silently alter a badge. Assign one owner for the badge criteria and require that owner's sign-off before course structure, activity types or pass marks change. Keep a change log linking each badge version to the courses it covers. Decide in advance whether existing awards are re-evaluated when criteria change, and state that rule to learners in the badge description.
Testing the badge before issue
Run the full pathway with test learners on a staging copy of the site before any live badge is issued. Check that each criterion triggers at the expected point, that the badge image and description display correctly, and that the issued credential carries the right metadata. Repeat the test after each Moodle minor release or plugin update, because badge handling is part of the platform and can change with it.
Security and privacy considerations for issued badges
Badges leave the institution as signed, shareable records, so decisions about identity, content and visibility need to be made before the first award. The cards below cover what each badge carries, what learners can expose by sharing it, and who can change badge configuration in your Moodle site.
Learner identity in issued badges
Each issued badge names its recipient, and the identifier used for that recipient becomes part of the credential that learners carry to other platforms. Confirm which identity field your site places in the credential, for example an email address or a stable identifier from your identity provider, and whether that value can be changed later. Decide whether the identifier is acceptable to share with third parties, because learners may publish the badge wherever they choose.
Course and grade information in badge content
Badge names, descriptions, criteria text and evidence links are copied into the credential, so they can expose course titles, activity names or grade thresholds. Review the wording of every badge and its criteria before publishing, and keep grades and assessment detail out of free text. Where evidence links point to course pages, confirm that a learner who shares the badge does not also expose enrolment or grade data behind a login.
Public visibility and sharing
A badge can be verified by anyone who holds its link, and learners decide whether to share it. Check which pages are reachable without a Moodle login, including the badge page and any public issuer profile, and confirm how private badges behave in your Moodle version. Document who may make a badge public and whether staff must approve a badge before it is made visible.
Issuer keys and identifiers
Issued badges depend on the issuer identity and the signing material behind it, so exposure or loss of keys affects every credential that uses them. Identify where your installation stores issuer keys and identifiers, who can read or replace them, and how they are covered by backups. Agree a rotation approach, and test a site restore with its keys to confirm that restored badges still verify.
Limiting badge administration roles
Creating, editing and awarding badges are controlled by Moodle capabilities assigned at site and course level, so broad teacher or manager roles can change criteria or issue credentials. Restrict badge configuration to a small named group, limit course staff to awarding where they need it, and review role assignments on a set schedule. Confirm which capabilities separate issuing from configuring in your Moodle version.
Retention and removal of badge records
Issued badges persist after a course ends, and a learner may ask for their data to be erased or a badge to be revoked. Decide how long awarded badges are kept, how revocation and deletion are recorded, and how Moodle's privacy tools treat badge records when an account is deleted. Confirm these obligations with your data protection lead before the first award.
Questions buyers ask before outsourcing Moodle badge work
Is a badge program a large effort compared with the Moodle platform work itself?
It depends on what you are adding to. A badge program is usually a smaller workstream than a platform build, migration or upgrade, but it touches many more people: course authors, badge designers, administrators and the staff who approve criteria. The work is mostly defining what each badge means, mapping it to course completions or activities, and testing that awards are issued correctly. If you are switching platforms at the same time, badge work should be scoped as a separate workstream so its dependencies on course structure are visible. Ask the partner to show how the badge work sits inside the overall plan and which parts depend on decisions still open elsewhere.
What drives the cost of Moodle Open Badges 3.0 work?
Scope is set by the number and complexity of badges and the rules behind them. The main drivers are the number of badges, how complex the award criteria are (single activity completion or several conditions combined), whether badges span multiple courses in a pathway, what sharing and verification the learner needs outside the institution, and how much testing and course author training is included. Each driver adds design, configuration and checking time. Costs are one-time for design, build and training, and recurring only where you ask for ongoing support or new badges later. Request a written scope that lists each badge, its criteria, the courses involved, the sharing requirements and the test cases.
Can our own team set up Open Badges 3.0 in Moodle without a partner?
Yes, many teams can, if they have Moodle administration skills and clear criteria. Open Badges 3.0 support was added in Moodle 4.5, so your site must run a version that includes it, and you should confirm that version against your current release and upgrade plan. Internal teams often struggle less with configuration than with agreeing criteria, testing award logic across courses and handling learner sharing questions. A partner is most useful when the badge program depends on several courses, when criteria must be audited, or when your staff lack time. Ask the partner to state which parts you would own afterwards.
What does the institution need to provide for a badge project?
You need named owners for badge design, access to course data and a sign-off process for criteria. Assign someone who decides what each badge certifies, someone who can export or grant access to the courses and activities involved, and an approver who confirms the criteria before anything is awarded. Course authors must be available for review and training. Missing owners are one of the most common causes of delay, because criteria changes after build are costly to test again. Ask the partner for a list of inputs, due at which phase, and who signs off each one.
How long does a pilot for Moodle badges need to run?
The pilot length should be written into the scope, not assumed. A useful pilot covers a small set of badges, at least one cross-course pathway if you plan to use them, and real learners completing real activities so award logic is tested end to end. The duration depends on how many courses are involved, how often learners complete them, and how long your approvers need for review. No duration is set here, so request a pilot plan in the written scope that states the number of badges, the courses, the test cases, the exit criteria and the dates for review and sign-off.
What should we ask for in a quote for Moodle Open Badges 3.0 work?
Ask for a fixed scope that lists every deliverable and assumption. A quote should itemize badge design, criteria documentation, Moodle configuration, cross-course pathway setup, learner sharing checks, testing, course author training, documentation and handover. It should name what the institution provides and what happens if criteria change during build. Ask which items are one-time and which are optional ongoing support, and whether a pilot is included. DeployOpen does not publish a price list, so a quote follows from the written scope you agree.
What breaks most often with Moodle badges, and what should we check?
Criteria that depend on activities or courses that change later are the most common failure. Check that each badge criterion references stable course and activity settings, that cross-course rules still work after course copies or restores, and that issued badges and their verification pages behave as expected when learners share them outside the institution. Also check the hosting and data settings that affect public badge URLs, and confirm them with your Moodle version's documentation. Build test learner accounts for every pathway and keep a written record of the results before rollout.
Limits to confirm in your environment before rollout
Open Badges 3.0 issuing in Moodle depends on five facts about your version, your features, your sharing platforms, your hosting and your badge design. Each one has a clear source to check, and each should be confirmed in writing before the first badge reaches a learner.
Moodle version and 4.5 or later
Open Badges 3.0 support was added in Moodle 4.5, so a site on an earlier release cannot issue these badges until it upgrades. Moodle 4.5 is a long-term support release with security support until 4 October 2027. Confirm your exact version in your site's version information, and check the Moodle release notes for any upgrade path that runs further. Rehearse the upgrade on a copy of your site before production.
Badge features in your exact version
Check that each badge feature in your plan exists in the Moodle release you run. Features can differ between releases, so a guide written for a newer version may describe settings your site does not show. Compare your planned criteria, cross-course badges and sharing steps against the release notes for your version, then test each one in a staging copy of your site before you design any course around it.
External platforms learners will use
Learners share badges to platforms outside the institution, and each platform decides what it accepts and how it displays a badge. List the platforms your learners and employers actually use, then ask each vendor whether it imports Open Badges 3.0 and how it reads the badge data. Do not assume support from the name of the standard alone. Record the platforms you tested and the versions you tested them against.
Public badge URLs and TLS setup
Verification depends on badge URLs that outside platforms can reach over the public internet. Confirm that your reverse proxy, firewall and DNS expose those pages to external requests, and that your TLS certificate is valid, publicly trusted and renewed automatically. Test from outside your network, because VPN-only access or a private certificate authority can break verification that works on campus. From Moodle 5.1, the web server document root must point to the public directory.
Badge design stable enough to issue
An issued badge is a record that learners keep, so its name, description, criteria and image should be settled before the first award. Confirm with course owners and the badge issuing team that the wording and criteria will hold for the planned rollout. Test the full path of issue, share and verify in a test course with test learner accounts, and agree in advance how any later change will be explained to learners.
How DeployOpen scopes and delivers a Moodle badge program
DeployOpen plans and delivers Moodle Open Badges 3.0 as a project inside infrastructure you control, starting from the badge criteria your programs need. Work is fixed-scope, with scope, deliverables and timelines agreed in writing before build starts. Each stage below lists what you receive, so your team can check progress against it.
How we scope
- The written scope names which badges exist, who earns them and the criteria for each one.
- Criteria are mapped to course completions, activities and grades, including cross-course badges that draw on several courses.
- Scope also records the Moodle version and server stack the program will run on.
How we build
- Badge criteria are configured in a test copy of your Moodle site before anything reaches learners.
- Test cases cover awarding, criteria edge cases and whether a shared badge displays its criteria and issuer details.
- Any custom theme or plugin work is quoted separately and tested against your Moodle version.
How we hand over
- Handover includes a written record of each badge's criteria, the course mappings behind it and who can edit them.
- Your administrators receive a walkthrough of issuing and reviewing badges on your own site.
- Learner guidance explains how people share badges outside your institution and where to check them.
How we support
- Ongoing support, upgrades and testing are available as a retainer, scoped separately from the build.
- Each Moodle upgrade is planned with a retest of badge criteria, mappings and sharing.
- Confirm with us which Moodle release the program will target, since version requirements differ by release.
