Is SCORM content secure? An honest answer

What SCORM does not protect

Is SCORM content secure? Not by itself. SCORM is a packaging and runtime specification, and it contains no encryption, no licensing, and no access control of any kind. Whatever security a course has comes entirely from the platform hosting it and the network in front of that platform. The zip and everything inside it are plain files.

This surprises people because the word "package" suggests something sealed. It is not. A SCORM package is a container in the sense a folder is: it groups files and describes them. The specification's job is interoperability — making a course built in one tool run in an LMS built by someone else — and its authors left security to the hosting platform, because they had no way to know what platform that would be.

So the honest framing is this. SCORM gives you a distribution format and a reporting channel, and nothing for confidentiality, integrity, or licence enforcement. If those matter, they have to come from elsewhere — and it is worth knowing where the gaps are before you tell a stakeholder a course is "protected".

The zip is the course

Unzip any SCORM package and you have the entire course sitting in a folder. There is no encrypted blob, no licence file, and no check that would notice the files had been copied. A typical package looks like this:

imsmanifest.xml
index.html
scorm_api.js
content/page-01.html
content/page-02.html
assets/module.pdf
assets/intro.mp4
assets/quiz-data.json

Three consequences follow, and all three are practical.

• The media is downloadable. Once an LMS extracts the package, it serves those files to a browser over HTTP. A learner who opens developer tools can see every request and save the PDF or the video. Often no devtools are needed: the file URL is guessable from the page URL.
• The logic is readable. JavaScript in a package can be minified, but minification is not encryption. Anyone who wants to read how the course scores a quiz can read it.
• The answers are often in there. SCORM has no server-side scoring. The course decides whether the learner passed and then reports that decision through the runtime API. That means the marking logic, and usually the answer key, ships inside the package — in the JavaScript or in a data file like the quiz-data.json above.

What does the LMS actually control?

The LMS is where the real controls live, and they are narrower than most assume. It controls who reaches the launch URL — that is authentication and enrolment, and it is genuine protection. It may also serve the extracted content through a session-checked handler, so an unauthenticated request is refused. Many platforms do not, and serve the extracted folder statically from a path that only needs to be known, not authorised.

That last row is the one that costs money. Send a SCORM package to a client to run in their LMS and you have handed over the course permanently. There is no clock in it and nothing to switch off. If they do not renew, the course keeps running. Access control at their login protects them, not you.

What dispatch adds

Dispatch is the one structural answer SCORM-adjacent tooling offers, and it is worth being precise about what it fixes. A dispatch package is a thin launcher: a small SCORM shell with a manifest and a few kilobytes of JavaScript that, when launched, opens the real course from a server you control and relays the runtime calls back to the host LMS. The client imports the launcher. The content never leaves your infrastructure as a file.

That genuinely removes the biggest exposure in the previous section. The zip you distribute contains no media, no course logic, and no answer key, so there is nothing in it to extract. It also gives you controls the specification has none of: you can expire a dispatch, revoke it, cap registrations, and update the course centrally without anyone re-importing anything. How dispatch works covers the mechanics.

What dispatch does not do is protect the content once a session is running. The learner's browser still fetches and renders your files, so the same network panel still shows the same media. Dispatch changes distribution from "here is the course" to "here is permission to launch the course" — which is a licensing control, an important one, and not a confidentiality one. It also adds a hard dependency: if your dispatch host is unreachable, every course everywhere fails to launch, which is a trade-off to weigh alongside hosting SCORM outside an LMS generally.

Where DRM is a separate question

DRM answers a different question from SCORM, and conflating them is where most confusion starts. SCORM asks "how does this course run in an LMS and report progress". DRM asks "how do I keep controlling this file after I have delivered it" — encryption at rest, keys issued per user, restrictions on copying, printing or offline retention, expiry, and revocation.

SCORM has no hooks for any of that: no data model element expresses a licence, no manifest field describes rights, and nowhere in the runtime does the LMS ask permission to display anything. If your valuable asset is a document or a video, DRM applies to that asset inside its own viewer — not to the SCORM wrapper around it. In practice the package embeds a player that streams the protected asset from a service that enforces the rules, and the protection belongs to that service, not to SCORM.

It is also worth saying plainly: anything a browser renders can be photographed off the screen. Protection at this layer raises the effort required and creates accountability — per-user watermarks, access logs, the ability to cut someone off — rather than making copying impossible. That is a reasonable goal. "Nobody can ever extract this" is not.

Setting realistic expectations

Once you accept that the package is readable, the decisions get much easier. A short set of rules covers most situations:

1. Treat everything in the package as visible to anyone who can launch the course. This is the single assumption that prevents nearly every unpleasant surprise.
2. Keep genuinely sensitive material out of the package. Reference it from a system that can authorise each request, rather than shipping it as an asset.
3. Do not let client-side scoring decide anything high-stakes. If a result affects certification, pay or compliance, the assessment belongs in the LMS's own quiz engine or a proctored tool, where the marking happens server-side.
4. Never ship the answer key when the result matters. If the course must contain the quiz, accept that the quiz is practice, and put the graded attempt elsewhere.
5. Use dispatch for third-party distribution. When content goes to a client or partner LMS, distributing a launcher instead of the course is the difference between licensing and giving it away.
6. Make the contract do the work it is for. For B2B content, the enforceable control over copying is commercial and legal, supported by watermarking and logs that let you trace a leak. No technical measure in this stack replaces it.
7. Say all of this to stakeholders early. "The LMS controls who can start it; the files themselves are not protected" is an accurate one-sentence summary, and it is much better delivered before a launch than after an incident.

None of this makes SCORM a bad choice. It is an interoperability standard doing the job it was designed for, and it does that job well. The mistake is expecting a second job from it that it never claimed.

Where SCORM Central fits

SCORM Central converts files you already have — PDF, PowerPoint, Word, or video — into SCORM 1.2, SCORM 2004, cmi5, or xAPI, and shows you the manifest, the full runtime log, and a conformance report on every build, so you can see exactly what a package will report before an LMS does. See how it works, or start with one file.