Forem: Bhavesh Pawar

How to Build vs Buy Your LMS Integration in 2026 (A Framework for Edtech Teams)

Bhavesh Pawar — Tue, 14 Apr 2026 10:19:04 +0000

At some point every edtech product team faces this decision: build the LMS integration in-house or buy a third-party solution. Most teams make this call too quickly, based on cost estimates alone. Here's the framework that actually produces the right answer.

Why this decision matters more than it looks

LMS integrations are not a one-time project. They're ongoing maintenance. Canvas updates its API. Moodle releases a new version. Blackboard changes its authentication flow. Every update is a potential breaking change you need to respond to.

When you build in-house, your team owns that maintenance indefinitely. When you buy, someone else does - but you're dependent on their roadmap, their reliability, and their pricing.

The decision isn't just about the cost to build. It's about the cost to own.

When to build

LMS integration is core to your product's value. If your product's competitive advantage is specifically how it integrates with LMS platforms - custom grade passback workflows, deep content embedding, real-time data exchange - buying a generic integration layer will cap what you can build. You need the control that comes from owning the integration.

You're targeting a single LMS deeply. If 90% of your customers are on Canvas and you need Canvas-specific features - Canvas-native assignment creation, gradebook features beyond basic AGS, roster sync - a custom integration built for Canvas will outperform any generic solution.

Your team has LMS integration expertise. Building an LTI 1.3 integration from scratch without experience leads to months of debugging edge cases across platforms. If your team has built LMS integrations before, the build path is faster and less risky.

You have complex compliance requirements. If your integration needs to handle specific data flows, custom audit logging, or compliance requirements that a generic solution doesn't support, you'll spend as much time customizing the bought solution as you would building.

When to buy

LMS integration is a checkbox, not a differentiator. If you need basic SSO, roster sync, and grade passback - and the details of how those work don't give you a competitive advantage - buying saves you 3 to 6 months of integration work and lets your team focus on what actually differentiates your product.

You need to support multiple LMS platforms quickly. Building and maintaining separate integrations for Canvas, Moodle, Blackboard, and Brightspace is significant ongoing work. Companies like Edlink offer unified APIs that abstract LMS differences. If multi-LMS support is a sales requirement but not a product differentiator, buying is almost always faster.

Your team doesn't have LMS expertise. LTI 1.3, AGS, NRPS, Deep Linking - these are specific technical areas with real learning curves. Hiring or developing that expertise takes time. A bought solution lets you move forward while your team builds knowledge.

You're pre-product-market fit. Before you know exactly which LMS features your customers need most, building a full custom integration is a risk. A bought integration gets you to market faster so you can learn what actually matters before investing in building it yourself.

The cost comparison that matters

Most teams calculate build cost as engineering time to implement. That's the wrong number.

The real cost is: implementation time + ongoing maintenance per year + cost of downtime when an LMS update breaks your integration + opportunity cost of your team not working on product.

For a team supporting 3 LMS platforms, ongoing maintenance can run 20 to 40 engineering hours per month across updates, bug reports, and edge cases. At a conservative $150/hour fully loaded, that's $36,000 to $72,000 per year in maintenance alone - before any new feature work.

Third-party integration platforms typically run $12,000 to $60,000 per year depending on scale. For many teams, that's cheaper than the maintenance cost of building, before accounting for the initial implementation.

The questions to answer before deciding

Is LMS integration core to our product's value or is it infrastructure?
How many LMS platforms do we need to support in the next 12 months?
Does our team have LMS integration expertise today?
What does our LMS integration need to do that a standard solution doesn't support?
What's the actual ongoing maintenance cost of owning this in-house?

If LMS integration is infrastructure and you need multiple platforms - buy. If it's core to your value and you have the expertise - build. If you're not sure - buy first, migrate to custom later when you know exactly what you need.

FAQ

What are the main third-party LMS integration platforms?

Edlink offers a unified LMS API that abstracts Canvas, Moodle, Blackboard, Brightspace, and others. Clever and ClassLink focus on K-12 rostering. 1EdTech's reference implementations help with LTI specifically. The right one depends on what you need - SSO, rostering, grade passback, or content integration.

Can we start with a bought solution and migrate to custom later?

Yes, and this is often the right path. Buy to get to market, learn what your customers actually need from the integration, then build custom for the specific capabilities that differentiate you. The transition is work but it's manageable if you design your product layer to abstract the integration details from the start.

We built our own integration and it's breaking constantly. Should we switch to a bought solution?

Possibly. The question is whether the breakage is from edge cases you haven't solved yet (which will stabilize) or from ongoing LMS updates you'll need to chase indefinitely (which won't). If you're spending more than 20% of your engineering time on LMS integration maintenance, a bought solution is worth evaluating.

Does buying an integration solution mean we don't need LMS expertise on our team?

No. You still need someone who understands LTI, LMS data models, and how your product maps to LMS concepts. The bought solution abstracts the implementation details but you still need to know what to ask for and how to design your product around LMS constraints.

xAPI vs SCORM in 2026 - How to Pick the Right One Before You Build

Bhavesh Pawar — Tue, 14 Apr 2026 10:18:15 +0000

Most edtech teams pick SCORM because it's familiar and it works. Some teams pick xAPI because it sounds more modern. Neither is the right reason to choose a standard. Here's how to make the decision based on what your product actually needs.

What they solve

SCORM and xAPI solve different problems. They're not interchangeable and one isn't strictly better than the other.

SCORM packages your learning content into a zip file that any compliant LMS can import and run. It tracks basic completion data - did the learner finish, what was their score, how long did they spend. The LMS stores this data and shows it in its built-in reports. Setup is simple, compatibility is near-universal, and the tooling ecosystem is mature.

xAPI tracks learning experiences as a stream of events sent to a Learning Record Store. Instead of packaging content for one LMS, xAPI lets you record learning activity from anywhere - a web app, a mobile app, a simulation, a video - and aggregate it in a central data store. The data model is richer: instead of "completed with 80%", you can record "Sarah watched 3 minutes of the safety video, skipped the quiz, revisited section 2 twice, and completed the assessment on her third attempt from a mobile device."

Pick SCORM if

Your content is course-based and your customers use a standard LMS. If you're building compliance training, structured courses, or any content that needs to run inside Canvas, Moodle, Blackboard, or Brightspace without custom integration work - SCORM is the right choice. Every major LMS supports it, authoring tools export to it, and it requires no infrastructure beyond the LMS.

Your customers don't need advanced analytics. If completion rates and quiz scores are enough - which they are for most compliance and certification use cases - SCORM gives you that without building anything custom.

You need fast time to market. SCORM packages are well-understood, tooling is abundant, and implementation is straightforward. Articulate Storyline, Adobe Captivate, and dozens of other authoring tools export SCORM packages directly.

Pick xAPI if

You need to track learning that happens outside an LMS. If your product includes mobile learning, simulations, job aids, informal learning, or any experience that doesn't live inside a single LMS - xAPI is designed for this. SCORM requires the LMS to be present. xAPI doesn't.

You need behavioral analytics beyond completion and scores. If you want to know exactly where learners struggle in a simulation, how they navigate through content, or how learning activity correlates with on-the-job performance - xAPI gives you the data model to capture that. SCORM can't.

You're building for multiple delivery contexts. If the same learning content or activity needs to run in an LMS, a standalone web app, a mobile app, and a third-party platform - and you want unified reporting across all of them - xAPI with a centralized LRS is the architecture that supports this. SCORM ties you to the LMS as the delivery and reporting layer.

Your customers are L&D teams doing skills tracking or performance measurement. Enterprise L&D is moving toward learning analytics that connect training activity to business outcomes. xAPI is the data standard that enables this. If your buyers are asking for xAPI, it's usually because they want to feed learning data into a broader analytics infrastructure.

The practical tradeoff

SCORM requires no infrastructure investment beyond the LMS. xAPI requires a Learning Record Store - either a standalone LRS like Learning Locker, Watershed, or SCORM Cloud, or an LMS with a built-in LRS. Setting up an LRS, designing your statement vocabulary, and building reporting on top of xAPI data is significantly more work than packaging a SCORM file.

That extra work is worth it when your product genuinely needs what xAPI provides. It's not worth it when SCORM would solve the problem in a fraction of the time.

What most teams actually do

Most edtech products start with SCORM for LMS-based content delivery and add xAPI later when a specific customer requirement or product feature needs it. This is usually the right sequence. Solving for the most common use case first and adding complexity when you have a specific reason to is better than building xAPI infrastructure speculatively.

If you're building something new today and you're not sure which to pick - start with SCORM if your primary delivery context is an LMS. Start with xAPI if your product is fundamentally about learning analytics or cross-platform tracking.

FAQ

Can we use both SCORM and xAPI in the same product?

Yes. Many products use SCORM for LMS-based content delivery and xAPI for detailed analytics. Some SCORM wrappers emit xAPI statements alongside standard SCORM tracking, giving you both LMS compatibility and richer data. Tools like cmi5 - an xAPI profile - are designed specifically to bridge this gap.

Our customers are asking for xAPI. Does that mean we need to build an LRS too?

Not necessarily. Many customers asking for xAPI already have an LRS or use one provided by their LMS. Your product needs to emit well-formed xAPI statements. Where those statements go is something you can configure - your own LRS, your customer's LRS, or a cloud service.

Is SCORM going away?

No. SCORM 1.2 from 2001 is still the most widely deployed eLearning standard. It's not being replaced - xAPI extends what's possible, it doesn't replace SCORM for existing use cases. You'll find SCORM deployments in enterprises and educational institutions for the foreseeable future.

What is cmi5 and should I care?

cmi5 is an xAPI profile that defines a standard way to package and launch content using xAPI, similar to how SCORM packages content for an LMS. It gives you the data richness of xAPI with the packaging convenience of SCORM. It's gaining adoption but still less common than either SCORM or standalone xAPI. Worth knowing about, not urgent to implement unless a customer specifically requests it.

How to Send Grades Back to Canvas Using AGS in 2026 (Without Manual Sync)

Bhavesh Pawar — Tue, 14 Apr 2026 10:17:29 +0000

If your LTI tool runs activities in Canvas and instructors are manually copying grades from your tool into the Canvas gradebook - you're solving the wrong problem. AGS handles this automatically. Here's how to implement it.

What you need before you start

AGS requires LTI 1.3. If you're still on LTI 1.1, this won't work - the old outcomes service is a different, more limited mechanism. You also need LTI Advantage enabled on your Canvas developer key.

In Canvas, when you create a developer key for your LTI tool, make sure Assignment and Grade Services is checked under LTI Advantage Services. If it isn't enabled, your AGS API calls will return 401 errors regardless of how correctly you've implemented the service.

Step 1 - Capture the AGS endpoint at launch

When Canvas launches your tool via LTI, the id_token contains everything you need for grade passback. In the LTI claims, look for:

https://purl.imsglobal.org/spec/lti-ags/claim/endpoint

This claim contains the AGS endpoint URL and the scopes your tool has been granted. You need two scopes for full grade passback:

https://purl.imsglobal.org/spec/lti-ags/scope/lineitem - to create and manage gradebook columns
https://purl.imsglobal.org/spec/lti-ags/scope/score - to post scores

Store both the endpoint URL and the scopes from this claim. You'll need them for every AGS call. If you don't capture them at launch time, you'll need to re-launch to get them - there's no way to retrieve them after the fact.

Step 2 - Get an access token

AGS calls are authenticated with an OAuth 2.0 access token, not the LTI id_token. You need to request a token from Canvas's token endpoint using your tool's private key.

The token request is a client credentials grant using JWT assertion:

POST https://canvas.instructure.com/login/oauth2/token
Content-Type: application/x-www-form-urlencoded

grant_type=client_credentials
&client_assertion_type=urn:ietf:params:oauth:client-assertion-type:jwt-bearer
&client_assertion={signed_jwt}
&scope={space_separated_scopes}

The signed JWT must be signed with your tool's private key and contain your client ID as both the issuer and subject, Canvas's token endpoint as the audience, and a short expiry (under 60 seconds).

Canvas returns an access token valid for 1 hour. Cache it and reuse it for multiple AGS calls within that window.

Step 3 - Create a line item (gradebook column)

A line item is a gradebook column in Canvas. You need one line item per gradeable activity.

If your LTI resource link is already associated with a Canvas assignment, Canvas may have created a line item automatically. Check the endpoint URL from the launch - if it contains /line_items/{id}, a line item already exists for this launch. Use it directly.

If you need to create a new line item:

POST {lineitemsEndpoint}
Authorization: Bearer {accessToken}
Content-Type: application/vnd.ims.lis.v2.lineitem+json

{
  "scoreMaximum": 100,
  "label": "Module 3 Quiz",
  "resourceLinkId": "{resourceLinkId from launch}"
}

The resourceLinkId ties the line item to the specific LTI launch context. Include it so Canvas associates the gradebook column with the correct assignment.

Step 4 - Post a score

Once you have a line item URL, posting a score is one API call:

POST {lineItemUrl}/scores
Authorization: Bearer {accessToken}
Content-Type: application/vnd.ims.lis.v1.score+json

{
  "userId": "{Canvas user ID from launch}",
  "scoreGiven": 85,
  "scoreMaximum": 100,
  "activityProgress": "Completed",
  "gradingProgress": "FullyGraded",
  "timestamp": "2026-04-14T10:30:00Z"
}

Canvas updates the gradebook column for that student immediately. The grade appears in the instructor's gradebook without any manual action.

Use the user ID from the LTI launch sub claim - this is the Canvas user identifier that AGS expects. Don't use email addresses or other identifiers.

Common Canvas-specific issues

Scores not appearing in gradebook - check that activityProgress is set to "Completed" and gradingProgress is set to "FullyGraded". Canvas requires both to display the grade. Scores with other progress values may be stored but not shown.

401 errors on AGS calls - your developer key doesn't have AGS scopes enabled, or your access token request is missing the correct scopes. Go back to your Canvas developer key and verify Assignment and Grade Services is enabled.

Line item not found - the line item URL from the launch may have expired or the assignment was deleted in Canvas. Re-launch to get a fresh endpoint URL.

Scores posting for wrong student - you're using the wrong user identifier. Use the sub claim from the LTI id_token, not the custom user data you may have stored in your own system.

FAQ

Can we post grades outside of the LTI launch session?

Yes - that's the main use case. Store the line item URL and access token endpoint from the launch, then post scores whenever the student completes the activity, even hours later. Just request a fresh access token when the old one expires.

Does Canvas automatically create a line item when we create an LTI assignment?

Yes, in most cases. When an instructor adds your LTI tool as an assignment in Canvas, Canvas creates a line item automatically. The launch id_token will contain the existing line item URL in the AGS endpoint claim. Check for it before creating a new one to avoid duplicates.

What's the difference between scoreGiven and scoreMaximum?

scoreGiven is the student's raw score. scoreMaximum is the maximum possible score for the activity. Canvas calculates the percentage and displays it in the gradebook. Always include both - posting scoreGiven without scoreMaximum will cause display issues.

We're posting scores but they appear as zero in Canvas.

Check that scoreGiven is a number, not a string. Also verify that activityProgress and gradingProgress are set correctly. A score of 0 with "FullyGraded" is a valid submission that Canvas will display as 0%.

How to Debug a Failed LTI Launch in 2026 (A Practical Checklist)

Bhavesh Pawar — Tue, 14 Apr 2026 10:16:01 +0000

Your LTI tool isn't launching. The student clicks the link in the LMS and gets an error, a blank screen, or gets redirected back to the LMS. Here's how to find the problem fast.

LTI launch failures almost always fall into one of five categories: configuration errors, OIDC flow problems, token validation failures, state issues, or platform-specific quirks. Work through this checklist in order.

Step 1 - Check the basics first

Before anything else, confirm these:

Is your tool registered correctly in the LMS? Every LMS has its own external tool registration flow. Canvas, Moodle, Blackboard, and Brightspace all configure differently. Check that the client ID, deployment ID, and launch URL are entered exactly as your tool expects them.
Is your tool's public key or JWKS URL accessible? LTI 1.3 uses public key cryptography. The LMS needs to fetch your JWKS (JSON Web Key Set) to verify messages. If your JWKS endpoint returns an error or is blocked by a firewall, launches will fail silently.
Is your launch URL correct and publicly accessible? Test it directly in a browser. If it returns a 404 or redirects unexpectedly without LTI context, the URL is wrong.

Step 2 - Trace the OIDC flow

LTI 1.3 launches use an OpenID Connect third-party initiated login flow. It involves multiple redirects and is the most common source of confusion.

The flow works like this: the LMS sends an OIDC login initiation request to your tool, your tool responds with a redirect back to the LMS authorization endpoint, the LMS then sends the actual LTI message (id_token) to your tool's redirect URI.

Where it commonly breaks:

Login initiation URL mismatch - the URL you registered for OIDC login in the LMS must exactly match what your tool expects. A trailing slash difference or http vs https can break it.

Redirect URI mismatch - same issue. The redirect URI registered with the LMS must exactly match what your tool sends in the OIDC request.

State parameter not preserved - your tool generates a state parameter at login initiation and expects it back after the LMS redirect. If you're using serverless functions or stateless backends, the state may not be preserved between requests. Check that your state storage (session, database, or cache) is working correctly.

Cookie issues in iframe - if your tool launches in an iframe, Safari and some other browsers block third-party cookies by default. Your OIDC flow may rely on a cookie to preserve state, which Safari drops. If launches work in Chrome but fail in Safari, this is your problem. The fix is to use platform storage via postMessage or redirect to a new tab instead.

Step 3 - Validate the id_token

Once the OIDC flow completes, the LMS sends your tool an id_token containing the LTI launch data. Token validation failures are a common silent failure point.

Check each of these:

Signature verification - your tool should verify the token signature using the LMS's public keys. If the LMS has rotated its keys recently, your cached keys may be stale. Fetch fresh keys from the LMS's JWKS endpoint.
Issuer claim - the iss claim in the token must match the issuer you registered for this LMS platform in your tool. Case sensitive.
Audience claim - the aud claim must contain your tool's client ID.
Expiry - LTI tokens expire quickly, typically within a few minutes of issuance. If there's a clock skew between your server and the LMS server, tokens may arrive already expired. Check your server's time synchronization.
Nonce validation - your tool should validate that the nonce in the token matches one it generated. This prevents replay attacks. If your nonce storage is misconfigured, valid launches will be rejected.

Step 4 - Check platform-specific configuration

Each LMS implements LTI slightly differently. If your tool works on one platform but not another, the issue is usually platform-specific configuration.

Canvas - Canvas requires a developer key to be created and enabled before LTI tools work. Check that the developer key is active (not pending). Canvas also has specific requirements around the target_link_uri claim.

Moodle - Moodle's LTI configuration is in the External Tools section under Site Administration. The registration flow differs between Moodle versions. Also check that your tool's domain is not blocked by Moodle's security settings.

Blackboard - Blackboard auto-migrates LTI 1.1 links to 1.3 when you configure a 1.3 tool for the same domain. If you have both 1.1 and 1.3 configured and links are behaving unexpectedly, check whether Blackboard has auto-migrated links you weren't expecting.

Brightspace - Brightspace requires deployment IDs to be configured explicitly. A missing deployment ID in your tool's configuration will cause launch failures even if everything else is correct.

Step 5 - Enable logging and read the errors

If you've checked everything above and still can't find the problem, enable detailed logging on your tool's launch endpoint. Log the full OIDC request, the id_token claims, and any validation errors with their specific failure reason.

Most LTI problems produce a specific error that points directly to the issue - a claim mismatch, an expired token, a missing configuration value. Without logging, you're guessing.

Also check the browser console and network tab when triggering a launch. Some LMS platforms surface error details in the network response that aren't visible in the UI.

FAQ

The launch worked yesterday and broke today. What changed?

Most common causes: LMS updated and changed its JWKS URL or key rotation schedule, your SSL certificate expired, a deployment or configuration change in your tool, or the LMS rotated its signing keys. Start by checking the LMS JWKS URL and your SSL certificate.

We get a blank screen after the OIDC redirect. Where do we look?

This almost always means your tool received the id_token but threw an unhandled error during validation or session setup. Check your server logs for exceptions around token parsing. Also check whether your redirect URI is returning a valid response - a 500 error during the final redirect produces a blank screen.

Launches work for instructors but not students.

Check role-based access controls in your tool. Also check whether your tool expects certain claims that are present for instructors but not students. Some LMS configurations send different claim sets based on role.

The tool launches fine in development but fails in production.

Most likely a URL mismatch - your registered URLs use the development domain and haven't been updated for production. Also check environment-specific configuration like your JWKS URL, client ID, and private key.

What is AGS and When Does Your Edtech Product Actually Need It in 2026

Bhavesh Pawar — Tue, 14 Apr 2026 10:12:51 +0000

If you've built an LTI integration and grades aren't syncing back to the LMS automatically, you're missing AGS. If you're building a new edtech product and wondering whether you need it at all - here's the clear answer.

What AGS is

AGS stands for Assignment and Grade Services. It's one of three services that make up LTI Advantage - the extended capability layer built on top of LTI 1.3.

When a student completes an activity in your external tool, AGS is what sends their score back to the LMS gradebook. Without AGS, instructors have to manually enter grades, your tool and the LMS stay disconnected, and the integration feels incomplete to every teacher who uses it.

AGS does two things specifically. First, it lets your tool create a gradebook column in the LMS for a specific assignment - called a line item. Second, it lets your tool post a score against that line item for a specific student.

That's the whole thing. It sounds simple. The implementation has some edges worth knowing.

When you need AGS

You need AGS if any of these apply to your product:

Your tool includes assessments, quizzes, or any activity where students receive a score that instructors need in their gradebook. Without AGS, those grades live only inside your tool and instructors work from two separate systems.

You're selling to schools or universities where grade passback is a procurement requirement. Most institutions that use Canvas, Moodle, Blackboard, or Brightspace expect LTI tools to sync grades automatically. Asking instructors to manually transfer grades is a fast path to low adoption.

You want your integration to feel native inside the LMS rather than like a separate tool bolted on. AGS is part of what makes an LTI integration feel complete.

When you don't need AGS

Not every edtech product needs grade passback. You can skip AGS if:

Your tool is purely content delivery - videos, reading materials, reference resources - where there's no score to report back. An interactive textbook or a content library doesn't need grade passback.

Your tool tracks completion or engagement but not grades. Some products report that a student completed an activity without assigning a numeric score. LTI can pass a simple completion status without full AGS implementation in some cases.

Your primary customers are individual instructors or self-directed learners rather than institutions using a centralized LMS gradebook.

How AGS works in practice

When an instructor sets up your tool in their LMS course, AGS lets you create a line item - essentially reserving a gradebook column for your activity. You can do this at launch time or proactively if you have Names and Role Provisioning Services access.

When a student completes the activity in your tool, you post a result to that line item using the AGS endpoint. The LMS receives it and populates the gradebook column for that student automatically.

The score format is a decimal between 0 and 1, representing the fraction of the maximum score. If the maximum is 100 and the student scored 85, you send 0.85. The LMS handles the display formatting.

One thing to know: AGS calls are made server-to-server, not during the user's session. You need to store the line item URL and the service token from the LTI launch to make AGS calls later. If you don't capture those at launch, you can't do grade passback after the fact.

AGS vs the old LTI 1.1 outcomes service

LTI 1.1 had a basic outcomes service for grade passback, but it was limited and unreliable. It only supported a single score per launch, the passback was asynchronous and often inconsistent across LMS platforms, and there was no way to create gradebook columns programmatically.

AGS is more reliable, supports multiple scores per student per activity, lets you create and manage line items programmatically, and works consistently across LMS platforms that support LTI Advantage. If you're on LTI 1.1 and grade passback is important to your product, migrating to LTI 1.3 with AGS is the upgrade that makes it work properly.

The platforms that support AGS

Canvas, Moodle, Blackboard, and D2L Brightspace all support AGS as part of their LTI Advantage implementation. Schoology also supports it. If you're targeting any of these platforms and your product has gradeable activities, AGS should be in your integration.

FAQ

Can we implement AGS without LTI 1.3?

No. AGS is part of LTI Advantage which requires LTI 1.3 as the foundation. If you're still on LTI 1.1, you'd need to migrate to LTI 1.3 before implementing AGS.

What if the instructor hasn't set up a gradebook column before our tool launches?

You can create the line item programmatically at launch time as part of your LTI launch handling. You don't need the instructor to set anything up manually - AGS gives your tool the ability to create the column itself.

Does AGS work for group activities or only individual student scores?

AGS posts scores per student per line item. Group activities where every student gets the same score are supported - you just post the same score for each student individually. There's no native group submission concept in AGS.

What's the difference between AGS and Deep Linking?

Deep Linking is a separate LTI Advantage service that lets instructors browse and select specific content from your tool to embed in their course. AGS handles grade passback. They're independent - you can implement one without the other depending on what your product needs.

Why Being FERPA Compliant Does Not Make You COPPA Compliant in 2026

Bhavesh Pawar — Tue, 14 Apr 2026 10:11:45 +0000

This is the most common compliance mistake edtech companies make. They get FERPA right - signed DPAs, data used only for educational purposes, school official exception covered - and assume they're done. Then a procurement review or an FTC inquiry surfaces a COPPA gap they didn't know they had.

FERPA and COPPA are separate laws enforced by different agencies. Complying with one does not satisfy the other. If your product is used by K-12 students under 13, you need both.

What each law actually covers

FERPA - the Family Educational Rights and Privacy Act - governs how schools share student education records with third parties. It applies to you as a vendor through the school official exception, which allows schools to share student data with outside vendors performing educational services. FERPA is enforced by the US Department of Education.

COPPA - the Children's Online Privacy Protection Act - governs how online services collect personal information directly from children under 13. It applies to you as an operator, independent of any school relationship. COPPA is enforced by the Federal Trade Commission.

Two different laws. Two different agencies. Two different compliance requirements.

Why one doesn't cover the other

The school official exception under FERPA allows schools to share student data with vendors. But it doesn't give vendors permission to do whatever they want with that data. And it doesn't satisfy COPPA's requirements.

A platform cannot rely on school consent under FERPA to satisfy COPPA's parental consent requirements.

Here's where this gets concrete:

FERPA says: The school has authorized you to receive student data for educational purposes. Use it only for that purpose.

COPPA says: You are collecting personal information from children under 13. You need verifiable parental consent - unless the school is providing that consent on behalf of parents under COPPA's school authorization exception.

The school authorization exception exists in COPPA too, but it's narrower than most companies realize. It covers collection for educational purposes only. The moment you use student data for anything beyond the contracted educational service - analytics, advertising, AI model training, product improvement - school authorization doesn't cover it and you need separate parental consent.

Where the gaps actually appear

Analytics and tracking SDKs

A company can be FERPA compliant - signed DPAs, data used only for educational purposes - but still have a COPPA problem if they're running third-party analytics tools that collect behavioral data from students without proper consent. FERPA doesn't regulate your SDK choices. COPPA does.

Data retention

FERPA doesn't specify precise retention timelines. COPPA's 2025 amendments are explicit: children's data cannot be retained indefinitely and must be deleted when it's no longer needed for the specific purpose it was collected. A FERPA-compliant retention policy may still be non-compliant under COPPA.

Sub-processor accountability

FERPA requires you to disclose sub-processors in your DPA. COPPA goes further - under the 2025 amendments, you are expected to actively monitor and restrict how sub-processors use children's data. The standard is higher and applies independently of your FERPA obligations.

Biometric data

The 2025 COPPA amendments explicitly added biometric identifiers - facial recognition, voiceprints, fingerprints - to the definition of personal information. FERPA doesn't have equivalent specificity. If your product uses any biometric data, COPPA's requirements apply regardless of your FERPA compliance status.

What you need for each

For FERPA compliance:

Signed Data Processing Agreement with every school customer
Use of student data limited to the contracted educational purpose
Documented access controls for who can access student records
A process to support parent access and correction requests
A breach notification process

For COPPA compliance you additionally need:

School authorization mechanism or direct parental consent for data collection from under-13 users
Sub-processor inventory with accountability measures for each
Written data retention policy with specific deletion timelines
Separate consent flows for any data sharing beyond the educational service
A privacy policy that covers children's data specifically, including biometrics if relevant
Full compliance with the 2025 amendments by April 22, 2026

The practical test

Ask yourself: if a school district's legal team reviewed your COPPA compliance separately from your FERPA compliance, would they find gaps?

FERPA compliance means your contract with the school is correct and your data use is limited to educational purposes. COPPA compliance means your product's data collection, retention, and sub-processor practices meet the FTC's standards for child-directed services - regardless of what your school contracts say.

Both matter. Neither covers the other.

FAQ

If a school gives us authorization to collect student data, does that satisfy COPPA?

For educational use only - yes, that's the school authorization exception under COPPA. For any use beyond the contracted educational service - advertising, analytics, AI training, marketing - no. Separate parental consent is required.

We're already FERPA compliant. How much additional work is COPPA compliance?

The biggest gaps are usually the sub-processor audit, data retention policy, and privacy policy update. If your FERPA compliance is solid, you're probably 60-70% of the way there. The COPPA-specific gaps are identifiable and fixable.

Does COPPA apply to products used only by teachers, not students?

If teachers use your product and no student data flows through it, COPPA likely doesn't apply. If your product receives, displays, or processes any student data as part of its function, get a legal review.

What's the COPPA compliance deadline?

April 22, 2026 for full compliance with the 2025 amendments.

What Edtech Companies Need to Check for COPPA Compliance in 2026 (Full Checklist)

Bhavesh Pawar — Tue, 14 Apr 2026 10:10:14 +0000

The COPPA compliance deadline is April 22, 2026. If your edtech product is used by students under 13, this checklist covers everything you need to have in place. Use it as your audit framework before the deadline and as an ongoing reference after.

Data Inventory

[ ] You know exactly what personal information your product collects from users under 13
[ ] You know where that data is stored and in which country
[ ] You have documented who inside your company has access to student data and why
[ ] You have a complete list of every third-party SDK and service that touches student-facing parts of your product
[ ] You know how long you currently retain student data

Third-Party SDK and Sub-Processor Audit

[ ] Every SDK active on student-facing surfaces has been reviewed for what it collects
[ ] SDKs that collect device identifiers, behavioral data, or PII from students have been addressed - removed, replaced with a compliant version, or contractually bound
[ ] You have a Data Processing Agreement with every sub-processor that handles student data
[ ] Each DPA explicitly restricts the sub-processor from using student data for advertising, profiling, or purposes outside the service they provide to you
[ ] Your sub-processor list is current and documented

Consent and Authorization

[ ] You have a mechanism for schools to authorize data collection on behalf of parents for educational use (school authorization exception)
[ ] If you share student data with third parties for purposes beyond the core educational service - including advertising - you have a separate verifiable parental consent flow for that
[ ] Your consent language is clear and in plain terms that parents can understand
[ ] You do not bundle consent for advertising or data sharing into general terms of service

Data Retention and Deletion

[ ] You have a written data retention policy with specific timelines
[ ] Student data is deleted within a defined timeframe after the school relationship ends - typically 30 to 60 days
[ ] You have a process to respond to deletion requests from schools or parents
[ ] Indefinite data retention has been eliminated from your practices and your policy documents

Biometric and Sensitive Data

[ ] If your product uses facial recognition, voiceprints, fingerprints, or retina scans - these are now explicitly covered as personal information under the 2025 COPPA amendments
[ ] Biometric data collection from students under 13 has appropriate consent and is covered in your privacy policy
[ ] You have assessed whether any AI features in your product generate or process biometric identifiers

Privacy Policy

[ ] Your privacy policy is education-specific - not a generic SaaS policy
[ ] It describes what personal information you collect from children under 13
[ ] It lists the specific third parties or categories of third parties you share data with and the purposes for that sharing
[ ] It covers biometric data if your product uses any
[ ] It explains parent and student rights to access and delete data
[ ] It has been reviewed or updated since the 2025 COPPA amendments

Data Processing Agreements with Schools

[ ] Every school customer has a signed DPA in place
[ ] Your DPA template covers the school official exception requirements under FERPA
[ ] Your DPA lists your current sub-processors
[ ] Your DPA includes breach notification timelines - most districts require 72 hours
[ ] Your DPA defines what happens to student data when the contract ends

Security Controls

[ ] Student data is encrypted in transit and at rest
[ ] Access to student data inside your company is limited to people who need it for the contracted service
[ ] You have multi-factor authentication on systems that hold student data
[ ] You have a written incident response plan for data breaches
[ ] You have audit logging in place to track access to student data

Breach Notification

[ ] You have a process to identify when student data has been compromised
[ ] You know which school customers to notify and how
[ ] Your notification timeline is documented and aligns with your DPA commitments and applicable state laws
[ ] Key contacts at each school customer are documented

Documentation and Evidence

[ ] Your compliance effort is documented - even an incomplete process with a clear roadmap is better than no documentation
[ ] Your sub-processor list is maintained and up to date
[ ] Your privacy policy reflects your current data practices
[ ] Your DPA template has been reviewed by a lawyer who understands edtech and student privacy

If you can check all of these, you are in good shape for April 22

If you can't, prioritize in this order: sub-processor audit first, then retention policy, then privacy policy update, then DPA review. Those four address the most common compliance gaps and the ones districts and regulators check first.

FAQ

Do we need all of this before April 22?

Full compliance by April 22 is the goal. If you're starting late, document your progress and continue working. The FTC enforces against companies that show no effort. A credible compliance roadmap matters.

We're a small team. Which items are most critical?

Sub-processor audit, data retention policy, and privacy policy update. These three address the most visible gaps in a procurement review and the areas where COPPA violations are most commonly identified.

Does this checklist cover FERPA as well?

Partially. The DPA and security sections overlap with FERPA requirements. But FERPA and COPPA are separate frameworks - being compliant with one doesn't mean you're compliant with the other. A separate FERPA review is worth doing alongside this checklist.

How to Audit Your Third-Party SDKs for COPPA Compliance Before April 22 2026

Bhavesh Pawar — Tue, 14 Apr 2026 10:08:47 +0000

April 22, 2026 is the full compliance deadline for the FTC's updated COPPA rule. Most edtech teams are focused on their own data practices - consent flows, retention policies, privacy policies. What they're missing is the risk sitting in their SDK list.

The fastest path to a COPPA violation is not your own code. It's the analytics tool, crash reporter, or A/B testing library you added 18 months ago and haven't thought about since.

Here's how to audit your third-party SDKs before the deadline.

Why SDKs are your biggest COPPA risk

Under the updated 2025 COPPA rule, you are responsible for how your sub-processors use children's data. That means every SDK and third-party service in your product that touches student data is your compliance liability - not just your own database.

The FTC doesn't accept "we didn't know what the SDK was collecting" as a defense. If you're building an edtech product used by students under 13, you're expected to know exactly what every third-party component is doing with their data.

Step 1 - Build your SDK inventory

Start by listing every third-party library, SDK, and service integrated into your product. Include:

Analytics tools (Google Analytics, Mixpanel, Amplitude, Segment)
Crash reporting (Sentry, Crashlytics, Bugsnag)
A/B testing (Optimizely, LaunchDarkly, VWO)
Support and chat (Intercom, Zendesk, Crisp)
Marketing and email (HubSpot, Mailchimp, Customer.io)
Infrastructure that processes user data (AWS, Supabase, Firebase)
Any advertising or attribution tools

For each one, answer two questions: does it collect or process any data from student-facing parts of your product, and is it contractually bound to handle that data in a COPPA-compliant way?

Step 2 - Identify which ones touch student-facing surfaces

Not every SDK is a problem. An analytics tool that only fires on your admin dashboard is different from one that fires on student-facing pages.

Map each SDK to where it runs in your product. A crash reporter running across your entire app - including student sessions - is in scope. A payment processor that only runs on your billing page is not.

Focus your audit on SDKs active in any part of the product that students under 13 access.

Step 3 - Check what each SDK actually collects

For SDKs that do touch student-facing surfaces, review their data collection practices:

Does it collect device identifiers (IDFA, GAID, device fingerprints)?
Does it track behavioral data (clicks, sessions, page views)?
Does it set persistent cookies or use local storage?
Does it share data with third parties for advertising or profiling?

Most analytics SDKs collect device identifiers and behavioral data by default. Most crash reporters collect device information and session data. That data, collected from students under 13 without proper consent mechanisms, is a COPPA compliance gap.

Step 4 - For each risky SDK, choose one of three options

Remove it - if the SDK isn't essential and the compliance risk isn't worth the benefit, cut it. This is the cleanest solution.

Replace it - some SDKs offer COPPA-compliant or child-safe versions with data collection restrictions. Google Analytics has a data collection restriction mode for child-directed content. Firebase has similar controls. Check if your current SDK has a compliant configuration before replacing it entirely.

Document and contractually bind it - if the SDK is essential and has a compliant configuration, document it in your sub-processor list and ensure you have a Data Processing Agreement that covers COPPA obligations. The DPA needs to explicitly restrict the sub-processor from using children's data for advertising, profiling, or purposes beyond the service they're providing to you.

Step 5 - Update your sub-processor list and DPA

Once your audit is complete, your sub-processor documentation needs to reflect reality. Your privacy policy must list the categories of third parties you share data with. Your Data Processing Agreements with school customers need to include your current sub-processor list.

If you've removed or replaced SDKs as a result of this audit, update both documents to reflect the changes.

The audit takes one day

For most small edtech teams, a thorough SDK audit takes 4 to 8 hours. One person can run it. The output is a spreadsheet with every SDK, whether it touches student-facing surfaces, what it collects, and how you've addressed it.

That document also serves as evidence of your compliance effort - which matters if a school district reviews your security posture or the FTC asks questions.

FAQ

Does Google Analytics violate COPPA on its own?

Not automatically. Google offers a data collection restriction setting specifically for child-directed content that limits what Google collects and how it uses the data. If you're using GA on student-facing pages without this restriction enabled, that's a compliance gap to fix.

What if a required SDK doesn't have a COPPA-compliant configuration?

You have two options: find a replacement that does, or limit the SDK to non-student-facing parts of your product. Running a non-compliant SDK only on admin or instructor interfaces is generally acceptable - the issue is when it runs on surfaces that students under 13 access.

Do we need a DPA with every SDK provider?

For sub-processors that handle personally identifiable information from students, yes. Many major providers - Google, AWS, Stripe - have standard DPAs available on their websites. For smaller providers, you may need to request one directly.

What counts as "collecting" data under COPPA?

Any SDK that automatically gathers information from a device - device identifiers, IP addresses, behavioral data, usage patterns - is collecting data under COPPA even if you never explicitly send it student PII. Passive collection through device fingerprinting or tracking pixels counts.

How to Write a Data Processing Agreement for a School in 2026 (What They'll Ask You to Sign)

Bhavesh Pawar — Tue, 14 Apr 2026 09:47:39 +0000

A Data Processing Agreement is not optional. Under FERPA, before a school can legally share student data with your product, a signed DPA needs to be in place. Without one, most districts won't move forward. Have a DPA template ready before you need it.

What a DPA actually is

A DPA is a contract between you (the edtech vendor) and the school district (the data controller). It defines what student data you receive, what you're allowed to do with it, how long you keep it, and what happens if something goes wrong.

It's the legal document that makes you a FERPA-compliant "school official" — the designation that allows schools to share education records with third-party vendors without individual parental consent.

What your DPA template needs to cover

1. Scope of data — Define exactly what student data your product receives. Be specific.

2. Purpose limitation — Specify you will only use student data for the educational service described. You cannot use it for advertising, product development, or any commercial purpose.

3. Sub-processors — List every third-party service that touches student data. Each needs to be disclosed and contractually bound to the same data protection standards.

4. Data retention and deletion — Specify how long you retain student data and what triggers deletion. Typically 30 to 60 days after contract termination. COPPA now explicitly prohibits indefinite retention.

5. Security measures — Describe your technical controls: encryption, access controls, MFA, audit logging, incident response.

6. Breach notification — Define your process for notifying the district if student data is compromised. Most districts require notification within 72 hours.

7. Parent and student rights — Acknowledge FERPA rights and specify how you'll support the district in responding to access requests.

8. Term and termination — Define the contract duration and what happens to student data when the agreement ends.

Who should write it

Have a lawyer draft your DPA template — specifically one who understands edtech, student privacy, and FERPA. Generic SaaS data processing agreements don't address education-specific requirements and districts will send them back with revisions.

The DPA is a one-time legal investment that unblocks every school deal going forward.

How districts use DPAs

Many districts use platforms like StudentDPA to manage vendor agreements. If your DPA is already in their system, districts can approve you faster. Getting your DPA into platforms like StudentDPA removes a significant procurement hurdle.

FAQ

Can we use a standard SaaS data processing agreement?

No. Standard SaaS DPAs don't address FERPA requirements. Districts will reject them or require significant revisions.

What if a district wants to use their own DPA template?

This happens often. Review carefully and negotiate terms that are operationally problematic while accepting the rest.

Do we need a separate DPA for each district?

Each district signs their own copy, but you're working from the same template.

What's the StudentDPA Student Privacy Pledge?

A voluntary commitment by edtech vendors to specific student data protection practices. Signing it reduces friction during procurement with districts that use it as a screening tool.

What Changed in the 2025 COPPA Rule That Every Edtech Company Needs to Know Before April 22

Bhavesh Pawar — Mon, 13 Apr 2026 08:58:04 +0000

The last time COPPA was updated was 2013. A lot has changed since then - mobile apps, biometric data, AI-powered products, SDK ecosystems that track users across dozens of services. The 2025 amendments catch the law up to that reality.

The FTC finalized the updated rule on January 16, 2025. It went into effect June 23, 2025. Full compliance deadline: April 22, 2026. If you've been assuming the 2013 version still covers you, here's what you need to know.

What stayed the same

The core of COPPA hasn't changed. You still need verifiable parental consent before collecting personal information from children under 13. Schools can still authorize data collection on behalf of parents for educational use. The basic framework - notice, consent, access rights, security obligations - is intact.

What changed is the scope, the specificity, and the accountability requirements.

What changed - the 6 most important updates

1. Personal information now explicitly includes biometric data

The 2013 rule didn't specifically address biometrics. The 2025 amendments explicitly add facial recognition templates, voiceprints, fingerprints, retina scans, and similar identifiers to the definition of personal information.

If your product uses any biometric data - for attendance, identity verification, reading assessment, or AI personalization - that data is now regulated under COPPA. You need parental consent to collect it and can't retain it beyond its collection purpose.

2. Separate parental consent required for third-party data sharing

Under the 2013 rule, general consent covered most data uses. Under the updated rule, you need separate, explicit, verifiable parental consent before sharing children's data with third parties for targeted advertising or other commercial purposes.

You cannot bundle this consent into general terms of service. If you share data with advertising networks, analytics platforms, or marketing partners, you need a separate consent flow specifically for that purpose.

3. Stricter data retention - no more indefinite storage

The updated rule makes explicit what was previously implied: you can only retain children's personal information for as long as reasonably necessary to fulfill the specific purpose for which it was collected. Indefinite retention is prohibited.

This means you need a written retention policy with specific timelines. "We keep data until users delete their accounts" is no longer acceptable. You need to define when data is deleted and automate that deletion.

4. You are now accountable for your sub-processors

This is the change that catches most edtech companies off guard. Under the updated rule, primary operators - meaning you - are expected to monitor and restrict how third-party services use children's data you share with them.

Your SDK inventory is your compliance responsibility. Analytics tools, crash reporters, A/B testing platforms, advertising SDKs - if they touch children's data, you need to ensure they're operating within COPPA's requirements. "We didn't know what the SDK was doing" is not a defense.

5. Stricter notice requirements

When seeking parental consent, your notice must now include the identities or specific categories of third parties receiving children's data and the purposes for such disclosure. You can't use vague language like "trusted partners" - you need to be specific about who gets the data and why.

6. Safe harbor programs now require public disclosure

If your company is part of a COPPA Safe Harbor program, those programs are now required to publicly disclose their membership lists and submit additional reports to the FTC. This increases transparency and accountability across the entire safe harbor ecosystem.

What the FTC declined to change

The FTC chose not to finalize several proposed amendments related specifically to edtech, citing concerns about potential conflicts with upcoming FERPA regulation updates. This means the school authorization exception - which allows schools to consent on behalf of parents for educational technology services - remains in place under existing guidance rather than being codified in the rule.

This is good news for edtech companies in the short term. But the FTC explicitly stated it will continue to enforce COPPA in the edtech context and may revisit these provisions depending on how FERPA regulations evolve.

What this means if you were compliant under the 2013 rule

Being compliant in 2024 does not mean you're compliant now. The specific areas to review:

Do you collect or use any biometric data? That's newly regulated.
Do you share student data with any third-party services? You now need explicit consent and accountability measures.
What is your data retention policy? Indefinite retention is now prohibited.
Have you audited your SDKs and sub-processors against the new accountability requirements?

If the answer to any of these is "not sure" - that's your compliance gap.

FAQ

Did the FTC change what counts as a "child-directed" service?
Yes - the updated rule added examples of evidence the FTC may consider when determining if a service is child-directed, including marketing materials, representations to consumers, and the nature of the content. If you've been operating in a gray area on this, the updated guidance makes it easier for the FTC to establish that your service targets children.

We use Google Analytics on our platform. Is that a problem?
It depends on whether Google Analytics is active in parts of your product that students use and what data it collects. Google offers a version of Analytics with data collection restrictions for sites directed to children. Review your implementation and consult the terms of your agreement with Google.

Does the school authorization exception still apply after the 2025 updates?
Yes. Schools can still authorize data collection on behalf of parents for educational technology services. But this exception only covers educational use - you still cannot use school-authorized data for advertising or commercial purposes, and the updated accountability requirements for sub-processors apply regardless of how consent was obtained.

What's the penalty for non-compliance?
COPPA violations carry penalties up to $51,744 per violation. In cases involving children's data, the FTC has historically calculated penalties based on the number of affected children. The Cognosphere (Genshin Impact) settlement in 2025 was $20 million. YouTube's COPPA settlement was $170 million.

COPPA Deadline: April 22, 2026 - Your 6-Step Checklist If You Haven't Started Yet

Bhavesh Pawar — Mon, 13 Apr 2026 08:56:20 +0000

April 22, 2026 is 9 days away. If your edtech product is used by children under 13 and you haven't reviewed the FTC's updated COPPA rule, you're out of time to plan - you're in execution mode now.

The updated rule has been in effect since June 23, 2025. Full compliance is required by April 22, 2026. COPPA violations carry penalties up to $51,744 per affected child. This is not a rule you want to be catching up on after a school district flags it in procurement or the FTC comes calling.

Here's exactly what you need to do before the deadline.

Step 1 - Map your data

You cannot fix what you haven't mapped. Before anything else, document:

What personal information your product collects from users under 13
Where it's stored and in which country
Who inside your company has access to it
What third-party services receive or process it
How long you currently retain it

This audit takes 2 to 4 weeks for most small edtech teams. If you haven't started, start today.

Step 2 - Audit every third-party SDK and service

The fastest path to a COPPA violation is not your own code - it's the analytics tool, crash reporter, or A/B testing SDK you added two years ago and haven't thought about since.

Under the updated rule, you are responsible for how your sub-processors use children's data. Go through every SDK and third-party service in your product. For each one: does it touch student data? If yes, is it contractually bound to COPPA-compliant data handling? If no - remove it, replace it, or get a data processing agreement in place.

Common ones to check: Google Analytics, Mixpanel, Intercom, Hotjar, Segment. If any are active in parts of your product that students use, review them now.

Step 3 - Fix your data retention policy

The 2025 rule explicitly prohibits indefinite data retention for children's data. You need a written policy that defines how long you retain student data and what triggers deletion.

At minimum: student data must be deleted within a defined timeframe after the school relationship ends - typically 30 to 60 days. "Until the user requests deletion" or "as long as the account is active" are not compliant answers.

Step 4 - Check your consent flows

If your product shares any student data with third parties for targeted advertising or purposes outside the educational service - you now need separate, explicit, verifiable parental consent for that. You cannot bundle it into general terms of service.

Most pure edtech products don't run targeted ads, so this step may not apply to you. But if you monetize through advertising or share data with marketing partners, separate consent workflows are required before April 22.

Step 5 - Update your privacy policy

Your privacy policy must:

Describe what personal information you collect from children under 13
List the specific third parties or categories of third parties you share data with
Explain the purposes for any data sharing
Cover biometric data if your product uses facial recognition, voiceprints, or fingerprints

Generic SaaS privacy policies don't cover these requirements. If yours hasn't been reviewed since 2023, it needs an update.

Step 6 - Review your Data Processing Agreements

Every school you work with should have a signed DPA in place. That DPA needs to reflect your current data practices and sub-processor list. If you've added new third-party services since you last updated your template, update it now.

What to prioritize if you're starting late

If you're starting from zero with 9 days left:

Audit sub-processors today - remove anything that tracks children's behavior and isn't essential
Write a data retention policy this week - even a one-page document is better than nothing
Update your privacy policy to list third parties - this is the most visible compliance signal
Document everything you're doing - the FTC's standard is "reasonable" compliance practices, and a documented process matters even if it's incomplete

You won't achieve full compliance in 9 days if you're starting from zero. But you can close the biggest gaps and have a credible compliance roadmap. That's what districts and regulators want to see.

FAQ

Does COPPA apply if our product is used by schools but we don't market directly to children?
Yes. If students under 13 use your product and it collects personal information from them - even indirectly through school accounts - COPPA applies. The school authorization exception covers schools consenting on behalf of parents, but only for educational use.

We only collect email addresses and usage logs. Does that count?
Yes. Email addresses are personal information under COPPA. Usage logs linked to identifiable students are covered too. The updated rule expanded the definition to include device identifiers, geolocation data, and biometric identifiers.

What if we miss the April 22 deadline?
Document your compliance progress and keep working. The FTC enforces against companies that show no effort, not just those that miss a deadline. A documented roadmap with real progress is better than silence.

We only work with higher education. Does COPPA apply?
COPPA covers children under 13. If your product is used exclusively by higher education students who are 18 or older, COPPA likely doesn't apply. If you have any K-12 customers or users under 13, it does.

What is COPPA in 2026 and When Does It Apply to Your Edtech Product

Bhavesh Pawar — Mon, 13 Apr 2026 07:36:32 +0000

COPPA is the law most edtech founders underestimate — until a school district flags it during procurement or the FTC comes knocking. The rules changed significantly in 2025 and the compliance deadline is April 22, 2026. If you're building a product used by children under 13, you need to understand what changed and what it requires from you.

What COPPA is

COPPA — the Children's Online Privacy Protection Act — is a US federal law that restricts how companies collect, use, and share personal data from children under 13 online. It's enforced by the Federal Trade Commission.

The FTC finalized major amendments to the COPPA rule on January 16, 2025. The updated rule went into effect June 23, 2025, with full compliance required by April 22, 2026. These are the first significant changes to COPPA since 2013 and they directly affect edtech companies.

When COPPA applies to your product

COPPA applies to you if your product is directed at children under 13, or if you knowingly collect personal information from children under 13.

In the edtech context, this means: if your tool is used in K-12 classrooms and collects any personal information from students — names, email addresses, user IDs, device identifiers, location data, or behavioral data — COPPA likely applies to you.

The school authorization exception allows schools to consent on behalf of parents for educational use. This means schools can authorize your collection of student data without requiring individual parental consent — but only for educational purposes, and only if your use of that data is limited to the service you were contracted to provide. You cannot use school-authorized data for advertising, product analytics, or any commercial purpose.

What the 2025 updates changed

Separate consent for data sharing — you now need explicit, verifiable parental consent before sharing a child's personal information with third parties for targeted advertising or other purposes. You cannot bundle this into general terms of service. Separate consent workflows for core functionality versus advertising are now required.

Stricter data retention — children's data can only be retained for as long as reasonably necessary to fulfill the specific purpose for which it was collected. Indefinite retention is explicitly prohibited. You need a defined retention policy and a process to delete data when it's no longer needed.

Expanded definition of personal information — the 2025 rule now explicitly includes biometric identifiers such as facial recognition, voiceprints, fingerprints, and retina scans. If your product uses any biometric data for attendance, identity verification, or personalization — that data is now regulated under COPPA.

Third-party accountability — you are now expected to monitor and restrict how your sub-processors use children's data. Every SDK, analytics tool, and third-party service that touches student data needs to be vetted. Cookie syncing, crash reporting tools, and A/B testing platforms are all in scope.

The line you cannot cross

The school authorization exception is not a blank check. It covers educational use only.

You cannot use student data to build user profiles for marketing. You cannot use it to train AI models without explicit authorization. You cannot share it with partners outside the educational purpose. You cannot retain it indefinitely after the school relationship ends.

The FTC takes this seriously. In 2025, Cognosphere paid $20 million in a COPPA settlement for collecting personal information from children without parental consent. COPPA violations carry penalties up to $51,744 per affected child.

What you need to have in place before April 22, 2026

A clear data map — what personal information does your product collect from users under 13, where is it stored, who has access, and how long you retain it
A sub-processor inventory — every third-party service that touches student data, with documentation of their data practices
Separate consent workflows — if you share data with third parties for any purpose beyond the core educational service, you need verifiable parental consent for that separately
A data retention and deletion policy — specific timelines, not vague language about "as long as necessary"
A privacy policy written for the education context — generic SaaS privacy policies do not cover COPPA requirements adequately

FAQ

Does COPPA apply if I'm not a US company?
If your product is used by children in the US, COPPA applies regardless of where your company is based. The FTC has enforcement reach over products targeting or knowingly collecting data from US children.

What's the difference between COPPA and FERPA?
FERPA protects education records held by schools and restricts how schools share that data with vendors. COPPA protects personal data collected directly from children online. Both can apply to the same product simultaneously. If your product is used in schools and collects data from students under 13, you need to comply with both.

Our product is used by teachers, not students directly. Does COPPA apply?
If teachers use your product and student data never flows through it — grades, names, identifiers — COPPA likely doesn't apply. If your product receives or displays any student data as part of its function, get a legal review.

The compliance deadline is April 22, 2026. What should we prioritize first?
Start with your data map and sub-processor inventory. You can't build compliant consent flows or retention policies until you know exactly what data you're collecting and where it goes. That audit typically takes 2 to 4 weeks and everything else builds on it.