How to Issue Verifiable Certificates from Moodle (and Why the Plugin Is Not Enough)

Moodle knows exactly who passed which course. What it cannot do is answer an employer five years later, when the course no longer exists and the person stopped being a student long ago. That gap, not the certificate design, decides whether what an institution issues means anything off campus.

Direct answer: issuing verifiable certificates from Moodle is not something the native tools solve on their own. There are three ways to hand out a certificate (the Custom Certificate plugin, native badges, and exporting to another platform by hand) and none of them produces a verifiable digital credential a third party can check independently and permanently. The plugin generates a PDF whose validation lives inside your own Moodle and is switched off for outsiders until an administrator enables it. Native badges are genuine Open Badges, but Moodle's own developer documentation states the platform supports versions 2.0 and 2.1, with 3.0 coming later. The fourth route is connecting the LMS to a credentialing platform over LTI 1.3: issuance is triggered by the course grade, and the credential lives outside the LMS with its own public verification page.

Key points

• The plugin's PDF is verified against your own Moodle. Every certificate carries a unique code, but the person receiving it can only check it if the administrator turned on "Allow anyone to verify a certificate". Otherwise, verifying requires an account with permissions inside the platform.
• Native badges are one generation behind the standard. They are Open Badges 2.0 and 2.1. Version 3.0, the one aligned with W3C Verifiable Credentials, is not there yet.
• The LMS and the credential run on different clocks. A course lasts a semester and the platform gets migrated every few years. A credential has to outlast an entire career.
• An LTI 1.3 integration removes the spreadsheet. POK reads the grade from the gradebook and issues when a student clears the threshold, with no exporting and no re-uploading.
• Nothing gets installed on the server. Registration happens from the Moodle admin panel, under External tool, with no SSH access and no code deployment.

The three ways Moodle already certifies

Moodle is by far the most widely deployed LMS in the world: its public statistics report more than 146,000 registered sites and around 529 million users, spread across 236 countries.

That means almost no institution starts its credentialing program from scratch. It starts from something already running in Moodle. So it is worth looking closely at what each of those three options actually proves, because the differences are not where you would expect.

1. The Custom Certificate plugin

This is the default choice nearly everywhere. According to Moodle's official documentation, Custom Certificate "allows the generation of dynamic PDF certificates with complete customisation via the web browser". You design the template by dragging elements around, add the activity to the course, and the student downloads a PDF.

It does include verification, which often comes as a surprise: every issued certificate gets a unique code that can be printed on the document, and there is a page where someone enters that code to confirm the certificate is authentic. So far, so solved.

The catch is who is allowed to use that page. The documentation is explicit: verifying requires the mod/customcert:verifycertificate capability, meaning a user with permissions inside your Moodle. Only when the administrator enables "Allow anyone to verify a certificate" can someone without a session do it. In other words, the default behaviour of the most widely installed certificate plugin in the ecosystem is that an outside employer cannot verify anything.

And even with the setting enabled, two things remain. The verification page lives on your Moodle's domain, so the proof depends on that URL still answering. And the artifact in circulation is a PDF, and a PDF can be edited.

The cost of all this is not theoretical, and the same office always pays it. As long as verification is not public, checking a certificate goes back to being one person in the registrar's office answering emails one at a time, which is precisely the work a digital certificate was meant to remove.

2. Moodle's native badges

This is the best designed of the three options and the least used. Moodle badges are real Open Badges: metadata baked into the image, issuance criteria, an identified issuer, and the option to push them to a digital backpack.

The limit is the version. Moodle's developer documentation puts it plainly: the platform currently supports Open Badges 2.0 and 2.1, which share a schema, and will add Open Badges 3.0 later because that schema is different. The version gap looks cosmetic and is not. Open Badges 3.0 is the release aligned with the W3C Verifiable Credentials data model, the one that lets a credential be checked cryptographically without depending on the issuer's server answering at that moment. Which is precisely the problem worth solving.

In the meantime, the native badge is hosted on your Moodle and its verification points there.

3. Exporting the list and loading it elsewhere

The third route is not a Moodle feature, it is what the academic team ends up doing: download the gradebook, filter who passed, clean the spreadsheet, upload it to a credentialing platform, and fix the mistyped email addresses.

It works, and it burns the most hours and accumulates the most errors. Every cohort pays the full cost again. As the program grows, the bottleneck stops being issuance and becomes the person building the spreadsheet.

	Custom Certificate (PDF)	Native badges	Manual export and upload	LTI integration with an external platform
What the student gets	A PDF file	An image with metadata	Depends on the platform	A credential in a digital wallet
Who can verify	Only users with permissions, unless public access is enabled	Anyone, against your Moodle	Depends on the platform	Anyone, from a public page
Where the proof lives	On your Moodle server	On your Moodle server	Outside the LMS	Outside the LMS, in the issuer's registry
Standard	None	Open Badges 2.0 and 2.1	Depends on the platform	Open Badges 3.0
If the course is deleted or the site migrates	Verification breaks	Verification breaks	Unaffected	Unaffected
Work per cohort	Initial setup	Initial setup	Hours of spreadsheet work	None
Can it be revoked	No	Yes, inside Moodle	Depends on the platform	Yes, with a public record

The real issue: the LMS and the credential do not age alike

Everything above has a single cause, and it is not a flaw in Moodle. Moodle does well what it was built to do: run a course, assess it, and keep the academic record while the person is enrolled.

The point is that the lifespan of a course and the lifespan of a credential have nothing in common. A course lasts a semester. The platform gets upgraded every year and migrated every few. Categories are reorganised, old courses are archived or deleted to free space, the student is unenrolled at graduation. The credential, meanwhile, has to still be standing when that person shows it in an interview seven years from now.

When the proof of an achievement lives inside the system that runs the courses, it inherits the wrong expiry date. It is not that someone will forge it: it is that on the day an employer goes to check it, the URL may not exist, the site may have changed domain, or verification may have ended up behind a login after a migration nobody connected to certificates issued back in 2021.

It is the same question any registrar's office asks before decommissioning an old system: who answers for these documents once this is gone. An LMS is an excellent course engine and a poor long-term registry, and no configuration setting changes that.

What an LTI 1.3 integration changes

LTI 1.3 is the 1EdTech standard that lets an LMS connect to an external tool without the two platforms merging. It is the same mechanism Moodle uses to plug in proctoring or a content library.

Applied to credentials, it changes three concrete things.

The grade pulls the trigger, not a person. In the credential setup you pick a course assessment and a minimum grade, for example passing above 80. POK reads that grade from the LMS grade service and issues to whoever qualifies. Nobody exports anything. Worth stating the edge case plainly: if the platform does not expose the grade through that service, the credential is delivered anyway, without the condition.

The credential is born outside the LMS. The record sits with the issuer, with its own public verification page, and that page does not depend on the course still existing or the Moodle site being online. It can also be issued with blockchain backing, which adds proof that does not even depend on the issuing platform. And because the registry belongs to the issuer, a credential issued in error can be revoked with a public record of it, which an already downloaded PDF does not allow.

Nothing is installed on the server. This point decides whether the project starts this month or next quarter. Registration happens from the Moodle admin panel, under External tool, by pasting a URL that POK provides. No plugin upload, no asking the hosting provider for SSH access, no maintenance window. From Moodle 3.10 onward it is enough to paste the URL and confirm; on earlier versions the connection is configured manually with the same values.

How it is wired into the course

Once the integration is registered, the credential is added to the course as an External tool activity, selecting the preconfigured POK tool. Opening it lets you define the credential design, whether it expires, how student data is mapped, and whether it is issued as a basic or a blockchain credential.

For the student the path is short: open the activity inside the course, fill in any missing profile data, and receive two emails, one to accept the credential and one with the credential itself.

For the coordination team there is a list with each student's status: pending, sent, or accepted. From there you can resend to the pending ones without anyone who already has it receiving a duplicate, which is the classic failure mode of spreadsheet-driven issuance.

What happens when the student leaves

This is the point that rarely makes it into the technical evaluation, and the one that most determines the value of the program.

With certificates hosted in the LMS, the graduate loses access when the account is deactivated. The PDF they downloaded is still in a folder somewhere, but nothing backs it any more. With a credential issued outside the LMS, the person keeps it in their digital credential wallet, shares it on LinkedIn with a link that resolves to the issuer's verification page, and it stays verifiable without the institution having to do anything.

One case that path does not cover is worth planning for: the employer who never got the link and only has the graduate's name. For that, an institution can publish a public credential search, a directory of what it issued that is reached through the holder's details instead of the link.

That is where the real return on connecting the LMS shows up. It is not saving the spreadsheet work, although it does save it. It is that every graduate becomes a permanent distribution channel for the institution, carrying proof anyone can check in one click. It is the difference between handing over a file and leaving a record.

Where to start

1. Check your Moodle version. From 3.10 onward registration is automatic. You will find it at the bottom of Site administration, Notifications.
2. Pick one pilot course, not the whole catalog. One with a clear assessment and a cohort finishing soon, so you can watch the full loop before scaling it. If the program stacks recognitions, decide up front which microcredential each course earns.
3. Define the issuance rule before the design. Which assessment counts and what the minimum grade is. That is the academic decision here; the rest is configuration.
4. Connect it and test with a real cohort. The Moodle integration guide walks through both version paths.

The same route covers Canvas, Blackboard, D2L Brightspace and Open edX, which also connect over LTI 1.3 from the integrations panel. An institution running more than one LMS, which is what usually happens when the graduate school and the undergraduate school chose differently, issues the same credentials from all of them.

POK is a 1EdTech certified Open Badges 3.0 issuer, holds ISO 27001 and SOC 2 certifications, and works with more than 1,100 institutions across more than 19 countries. The integration behaves the same on the free plan as on the blockchain-backed plans: what changes is where the record ends up, not how the data gets there from the course.

Frequently asked questions

Can you issue verifiable certificates from Moodle?

Yes, but not with Moodle's native tools alone. Moodle's Custom Certificate plugin generates a PDF with a verification code that is checked against the institution's own Moodle site, and only by users with permissions unless the administrator enables public access. Moodle's native badges are Open Badges 2.0 and 2.1, hosted on that same Moodle. For the credential to be independently and permanently verifiable, Moodle has to be connected over LTI 1.3 to a credentialing platform such as POK Proof of Knowledge, so the credential is issued and verified outside the LMS.

What is the difference between Moodle's Custom Certificate plugin and a verifiable digital credential?

Moodle's Custom Certificate plugin produces a PDF file and hosts its verification inside Moodle itself. A verifiable digital credential is issued into a registry outside the LMS, with its own public page, follows an open standard such as Open Badges 3.0, and can carry cryptographic backing on a blockchain. The practical difference shows up over time: the PDF depends on the Moodle URL staying alive and on the public verification setting staying on, while a credential issued through a platform such as POK survives an LMS migration, a deleted course, and a deactivated graduate account.

Are Moodle badges Open Badges 3.0?

No. Moodle's developer documentation states that Moodle supports Open Badges 2.0 and 2.1, which share a schema, and that it will add Open Badges 3.0 later because it uses a different schema. Version 3.0 is the one aligned with the W3C Verifiable Credentials data model, which is what allows a credential to be checked without relying on the issuer's server responding at that moment. That limitation belongs to Moodle's native badges, not to credentials issued outside the LMS: POK is a 1EdTech certified Open Badges 3.0 issuer.

Do you have to install a plugin on the server to connect Moodle to POK?

Not for the LTI integration. Registration happens from the Moodle admin panel, under Site administration, Plugins, External tool, Manage tools, by pasting the URL POK provides. It requires no SSH access, no code deployment, and no maintenance window. POK also offers an API-based integration through its own plugin, for institutions that prefer that route.

Can the credential be issued only to students who pass with a certain grade?

Yes. In the credential setup you select a course assessment and define the minimum grade, and POK reads that grade from the LMS grade service to issue only to those who reach it. If the platform does not expose the grade through that service, the credential is delivered anyway, without the condition. You can also skip the rule entirely and let students generate the credential when they finish the course.

Which Moodle version is required?

The connection works on currently supported versions. From Moodle 3.10, registration is dynamic: POK provides a URL, you paste it into Manage tools and confirm with "Add LTI Advantage". On Moodle 3.9 and earlier the tool is configured manually, entering the platform ID, the client ID and a web service token. Your installed version appears at the bottom of Site administration, Notifications.

What happens to the credentials if the institution migrates or shuts down its Moodle?

Nothing, if they were issued outside the LMS. That is exactly the reason to separate issuance from the course platform: the record and the public verification page live with the issuer, so a Moodle migration, an archived old course, or a deactivated graduate account do not affect the credential. If verification was hosted in Moodle instead, it stops answering and the certificates already issued lose their checkable backing.

Does the same integration work for Canvas or Blackboard?

Yes. POK connects over LTI 1.3 with Moodle, Canvas, Blackboard, D2L Brightspace and Open edX, and with Sana over xAPI. Canvas additionally supports an API Key connection. For an in-house campus or a custom development there is a custom integration by LTI URL or API Key, plus a REST API with webhooks. An institution running several LMS platforms side by side issues the same credentials from all of them.

Related reading

• How Employers Verify Digital Credentials in 2026
• Open Badge 3.0: The Complete Guide to Digital Credentials
• How to Implement Microcredentials at a University, Step by Step
• The Real Value of Digital Credentials: From Commodity to Trust Infrastructure

To see how POK connects to the LMS an institution already runs, review the plans and pricing or book a demo.

Last updated: September 14, 2026.