Edtech Fraud Prevention: Course Farming and Certificate Fraud

Online learning platforms sell three things fraudsters want: access to content, a credential with your name on it, and free trials that can be repeated. Each one gets abused in a different way, and each one leaves a different trace in your device and login data.

This post maps the common edtech abuse patterns to the signals that catch them, and to responses that don’t make life harder for honest learners.

Pattern 1: free-course and trial farming

The cheapest abuse is repetition. A learner finishes the free tier or the seven-day trial, then signs up again with another email. Some platforms give a free certificate for introductory courses, and those get farmed too, sometimes to pad CVs with dozens of credentials, sometimes to resell accounts.

What it looks like: many accounts on one device, created weeks apart, each using only the free allowance.

Signal: accountsOnDevice on the sign-up event, and the MULTI_ACCOUNT reason code (two or more distinct accounts on a device in 30 days).

Response: at enrollment, check how many accounts the device already holds. If it’s above your limit, create the account but withhold the trial or the free certificate. This is the same pattern as any SaaS free-trial problem:

const ev = await prynt.getEvent(req.body.requestId);
const prior = ev.accountsOnDevice.count;
const grantTrial = ev.decision !== 'block' && prior < 2;
const user = await createLearner(req.body, { trial: grantTrial });
await prynt.updateEvent(req.body.requestId, { linkedId: user.id });

Students share family laptops and library computers, so keep the limit above one, and prefer “no trial on this account” over “no account.”

Pattern 2: shared paid accounts

One person pays for an individual subscription and shares the login with a study group, or a “group buy” reseller sells seats on a single account. You lose revenue, and the account’s progress data becomes meaningless.

What it looks like: one account used from many devices, often in overlapping sessions, sometimes across cities.

Signals: the number of distinct visitorIds per account over a rolling window, the DEVICE_SPREAD reason code, and ACCOUNT_SHARING when one device hosts many accounts.

Response: count devices per account on login. Pass your user id as linkedId when you identify so every event is tied to the account:

// browser, after login
const { requestId } = await agent.identify({ tag: { action: 'lesson' }, linkedId: user.id });

Then, server-side, keep a set of verified visitorIds per account. When the number of devices in the last 30 days goes well past what a learner needs, show a soft prompt such as “This account is being used on many devices. Individual plans are for one learner,” and offer a team plan. Hard device caps cause support tickets when someone replaces a phone; a gentle limit with a “remove a device” option works better. Detecting credential sharing covers how to set the thresholds.

Pattern 3: exam handover and paid test-takers

This is the one that threatens the value of your credential. The named learner does the coursework, or doesn’t, and someone else takes the graded exam, either a friend with the password or a paid service that logs in remotely.

What it looks like: the exam session comes from a device that has never been used for this account’s coursework, or from a different country than every previous session, sometimes minutes after a session elsewhere.

Signals:

• New device at the exam. Compare the exam’s visitorId with the account’s device history.
• IMPOSSIBLE_TRAVEL. Two sessions too far apart in too little time.
• Remote-control and VM hints. VIRTUAL_MACHINE is common when a paid service operates inside a VM, and a datacenter IP on an exam (DATACENTER) is unusual for a student.
• Concurrent sessions. The learner’s usual device is active at the same time as the exam device.

Response: none of these prove who sat the exam. They tell you when to ask for stronger proof. For high-stakes credentials, route flagged exam attempts to a proctored retake or an ID check, and keep the reason codes with the attempt so the decision is explainable if the learner disputes it. Impossible travel detection explains how to avoid false positives from VPNs and mobile carriers.

Run the check at exam start, not only at submission. Stopping a handover before the exam is fairer to everyone than revoking a certificate afterwards.

Pattern 4: bots in the course catalog

Less glamorous but common: scrapers copying paid course content, and bots creating accounts to post spam in discussion forums. These look like any other automation: BOT, TLS_AUTOMATION, AUTOMATION_BEHAVIOR, and bursts from datacenter ranges. See scraping protection for the content side.

A signal map

Abuse	Main signals	Response
Free-course or trial farming	MULTI_ACCOUNT, accountsOnDevice	No trial or free certificate on repeat devices
Shared paid account	Devices per account, DEVICE_SPREAD	Soft device limit, offer team plan
Exam handover	New device at exam, IMPOSSIBLE_TRAVEL, VIRTUAL_MACHINE	Step up to proctoring or ID check
Paid test-taker service	Same device across many learners’ exams	Review all linked attempts; revoke if confirmed
Content scraping, forum spam	BOT, TLS_AUTOMATION, DATACENTER	Block or challenge

The fourth row is worth a closer look. A paid test-taking service handles many clients, so one of its devices shows up on exams for many different accounts. accountsOnDevice on an exam event lists every account you’ve linked to that device. A device with exam attempts for ten unrelated learners is a lead worth investigating, and every certificate it touched deserves review.

Privacy and fairness

Learners are often young, and education is sensitive. Identify only where there’s a reason: sign-up, login, exam start, payment. Prynt honors Global Privacy Control by default, so plan a path for learners whose browsers send it, such as a proctored exam option. Keep signals for as long as you need them to protect credentials and no longer.

Where to start

If you have to pick one, start with exam integrity. Log the device and reason codes for every graded attempt for a month without acting on them, then look at how many exams came from devices never seen on coursework. That number tells you how much your certificates are worth today, and how much stepping up the flagged attempts would protect them. Trial farming and account sharing can follow with the same integration, using the patterns in multi-accounting detection.