Strengthening lab launch security: the SCORM user identity gap and the move to API-based integration
At Skillable, the integrity of your training and certification programs is a priority which is why we don't recommend SCORM integrations for lab launches. Due to limitations inherent in the SCORM standard itself, we recommend other, more secure integrations. For customers with a unique set of requirements, SCORM is a last-resort option.
How a SCORM lab launch works
When you deliver a Skillable lab through SCORM, your Learning Management System (LMS) launches the lab content in the learner's browser. As part of that launch, your LMS supplies a user identifier that tells our platform which learner is starting the lab. This is by design.
· In any SCORM integration, the LMS is the system of record for your users. Your LMS authenticates each learner, manages their accounts and determines who is permitted to launch what.
· Skillable, as the lab provider, receives and acts on the identity your LMS asserts.
This point is central, so we want to be explicit about it: Skillable does not maintain a database of your end users.
We hold no record of your learner roster, no credentials and no connection to your authentication system. By design, we cannot independently verify that a user identifier passed to us corresponds to a real, authorized learner because that verification depends on information only your LMS holds. In a SCORM lab launch, authenticating users and asserting their identity is, and has always been, the responsibility of the customer's LMS.
The crux of the matter: The limitation lives in the SCORM standard
The SCORM standard provides no way for your LMS to cryptographically vouch for the user identity it passes to a tool. SCORM communicates through the browser at runtime, and the standard defines no signed, server-to-server mechanism for asserting "this is, verifiably, learner X." The organizations that authored SCORM acknowledged this characteristic of its security model more than 15 years ago.
Because the identifier is passed through the browser without a signature, a technically capable user can alter the identifier presented at launch. And because the standard provides no means to detect that alteration, neither the LMS nor any SCORM-conformant tool can reliably tell that it occurred.
This limitation is not unique to Skillable
It is a structural property of SCORM, and it affects SCORM-based integrations across the industry. A SCORM tool cannot close this gap while remaining within the SCORM model, because the missing piece − a verifiable identity assertion from the LMS − is something the standard simply does not carry. The appropriate response is not to patch a standard that was never designed to provide verified identity, but to adopt an integration model that was.
What this means for your programs
Because a SCORM launch cannot be cryptographically tied to a specific, verified learner, organizations using SCORM-based lab launches should be aware that:
· Per-user limits and concurrency controls can be circumvented, which can increase the lab and cloud consumption associated with your account.
· One learner's lab or certification-exam allocation could be consumed under another identifier.
Information tied to another learner's active or saved lab session could be returned at launch.
We share this openly and proactively with prospects and customers so that you can make an informed decision about your integration.
The path to a more secure integration
The reliable way to establish trusted identity at launch is a signed launch. This means your LMS cryptographically vouches for the learner and the receiving platform verifies that assertion before the lab starts. This is exactly what modern integration standards such as LTI 1.3 provide and it is the model behind Skillable's API-based lab launch integration.
Moving to the API-based integration
· Establishes a verified, tamper-evident identity for every launch.
· Restores the integrity of per-user limits, concurrency controls and consumption tracking.
· Aligns your deployment with an integration model designed for launching live, interactive lab environments − something SCORM, a content-packaging and progress-tracking standard, was never built to do.
How to migrate
We have published migration tools, documentation and step-by-step guidance at connect.skillable.com. Our team is ready to help you review your current SCORM-based deployment and plan a migration on a timeline that suits your organization. If you have questions or would like hands-on help, please contact us. Establishing verified identity is a shared effort between your LMS and our platform, and the API-based integration is how we make that possible together.
Note on CVE-2026-56877: A CVE was recently filed describing the known SCORM user-identity behavior discussed above. For clarity: This is not a vulnerability in Skillable's platform. It is a documented, structural characteristic of the SCORM standard itself, one that SCORM's own authors and the wider e-learning community have described publicly for more than 15 years. It was detailed in the LETSI white paper "SCORM Is Insecure: Secure It Before Adding Features" (August 2008) and again by SCORM's authors in SCORM Security: Some Perspective (April 2009). Because the limitation is inherent to how SCORM asserts identity through the browser, no SCORM-conformant tool, from any vendor, can resolve it while remaining within the standard. Attributing this standard-level characteristic to a single vendor mischaracterizes both the issue and its remedy, which is why Skillable only recommends SCORM as a last resort option. Fixing this issue isn’t a simple patch – it's a move to a signed, API-based integration model.