A few weeks ago I wrote that cybersecurity in our sector is a shared responsibility, and that the honest question underneath every incident is not "which vendor failed?" but "who is responsible for what?" The 1EdTech Board of Directors unanimously supported that response and the feedback from members, institutional leaders, and technology providers was immediate and constructive. The consistent message: agreement on the principle, and a desire to see it turned into specifics.
This note is that next step. It describes what 1EdTech is doing, and what the community can do with us, to raise the sector's security posture. It also clarifies how our standards and certifications –and indeed, those of other organizations–actually work, because in the wake of recent incidents some reasonable questions have surfaced that deserve clear answers.
I want to be direct about the frame first. A certification is not a guarantee that a product cannot be breached — ours, SOC 2, ISO 27001, none of them are, and none claim to be. What certifications and frameworks do is attest to the presence of specific controls and encourage strong practice. They are one part of a broader risk-management approach that also depends on institutional due diligence, sound contracts, disciplined identity and access management, and well-practiced incident response. When those elements work together, the sector is more resilient. When any one of them is treated as a substitute for the others, we are all more exposed.
What 1EdTech is doing
Our most direct lever is the security of the standards themselves and the certifications that verify them. On June 25, our CTO, Eric Hilfer, and Chief Architect, Tim Couper, walked the community through both our current posture and a concrete roadmap. The short version:
We are advancing the security framework toward the next generation of best practice. Our standards already implement modern, token-based security aligned with the internet's foundational bodies (the IETF and OpenID Connect). We are actively tracking the emerging OAuth 2.1 consolidation and, through our working groups, evaluating how to adopt its strongest ideas (such as making it impossible to reuse a stolen token) in a way that is additive and non-disruptive to existing implementations. This is the same forward-looking maintenance we have practiced for 25 years, not a reaction to any single event.
We are working to accelerate the retirement of deprecated standards. The clearest example is LTI 1.1, which relies on an older shared-secret security model and was deprecated years ago. Despite being deprecated years ago, it persists across the ecosystem for an understandable reason: many providers continue to support it because their customers still depend on it, and platforms cannot switch it off until those customers migrate. That is exactly the kind of shared problem the community has to solve together. To help, we are expanding migration playbooks and implementation resources — including our new standards portal and build portal, which can now take a developer from code to certification in minutes. The community is rallying and we are hearing about more and more definitive timelines to eliminate use of LTI 1.1 in provider products and institution-developed applications.
Working with 1EdTech members, we are strengthening what certification tells you. We are looking at ways to enhance certification to make security posture more transparent — for example, scoring whether an integration uses the most secure available option, flagging stale endpoints that still respond to a deprecated protocol, and expanding negative and edge-case testing. The goal is that a certification communicates not just "this conforms," but "this conforms using current, best-practice security."
We are evolving the rubrics and transparency tools. The community now maintains distinct rubrics for Data Privacy, Security Practices, Generative AI Data, and Accessibility. We are exploring how the security rubric can ask providers to disclose their posture on specific, EdTech-relevant attack vectors, and how the TrustEd Apps Management Suite can surface information like incident history and provider status more prominently.
We are convening the people who will do this work. This is community work, not something we invent alone. Active groups include the new Student Safety Task Force, the LTI Project Group (currently working through OAuth 2.1 alignment), the Security Committee, and the Edu-API and OneRoster steering bodies. Security will be a core focus of our Technical Congress (October 19–21, Milwaukee) and our Learning Impact Conference (February 8–10, San Antonio). Any members interested in joining this work may also contact us at support@1edtech.org.
Q&A: Understanding how the pieces fit
Recent discussion has understandably blurred a few distinctions. We have appreciated how so many have asked questions before making assertions or demanding prescribed actions. Here is how the pieces actually work.
Are data privacy and security the same thing? No. They are two separate concerns, and we maintain separate rubrics for each. Data privacy addresses what data is collected, who can access it, for how long, and what can be left out entirely. Security is the protection that keeps bad actors away from whatever data is collected. An organization can have a strong privacy policy and weak security, or vice versa — you need both, which is why we assess them separately.
What does a TrustEd Apps certification actually attest to? TrustEd Apps is not a single certification. It is a 1EdTech program that helps institutions identify products that meet specific interoperability, data privacy, security, accessibility, and other criteria. Within the program, products may earn certifications, such as the Data Privacy Certification, which reflects 1EdTech's review of a provider's policies against a member-developed rubric or complete provider self-assessments, such as the Security Practices Rubric, designed to support informed conversations with institutions. These certifications and assessments help establish a baseline and streamline the vetting process. They cannot prevent an attack; no certification or assessment can. Institutions should view them as one component of a broader due diligence process, not a replacement for their own security evaluation.
What is certification, and what is it not? Certification verifies conformance to a current standard, including its security requirements, demonstrated through our testing tools. It is an evidence-based signal for procurement and a mark of a provider's active commitment to current practice. It is not a guarantee of zero risk, cover for misconfiguration or deployment choices, or a substitute for platform-level security hygiene. In today's environment, an uncertified integration should be flagged for a closer look.
Was any 1EdTech standard the cause of recent incidents in the last few years? No. There have been dozens of incidents over the last five years, including institution and provider members of 1EdTech. Based on publicly disclosed information and independent analysis, the incidents usually involve multiple attack vectors, and key entry points have predominantly occurred in platform application layers, not in any 1EdTech standard. LTI, specifically, has not been used as an attack vector in any incident.
Then why does LTI keep coming up? Because it is worth being precise about versions. The only version of LTI that 1EdTech certifies is LTI 1.3, which uses modern cryptographic authentication (public/private keys, OAuth 2.0) rather than the shared secrets of the deprecated LTI 1.1. A product can be correctly certified for LTI 1.3 while a platform separately continues to enable 1.1 for legacy integrations its customers still rely on. That is a configuration and procurement reality across the sector — not a defect in the certification, which is version-specific by design. We explain the difference in plain terms in our recent post, "Why LTI 1.3 Matters."
So what should institutions do about LTI 1.1? Move off it. LTI 1.3 is the current standard, and the transition has never been easier. Our guidance is direct: require LTI 1.3 in procurement, audit your portfolio for anything still running a deprecated protocol, and decline to renew agreements with providers that remain on LTI 1.1 until they migrate to 1.3. Institutions are the most powerful force for moving the marketplace forward — when you set the expectation, providers can finally retire the legacy endpoints that widen everyone's risk.
An invitation
None of this is a response to any one commentator or moment. It is the next phase of work the community has been asking for, and the right phase for this point in the threat landscape. As our CTO put it, we would all rather roll up our sleeves together now than sit in the hot seat of the next incident.
If you are an institutional leader who has spent recent weeks rebuilding services, or a provider executive who has spent them answering hard questions, I want to hear from you — on the questions above and the ones I have not surfaced. Join a working group. Come to Tech Congress in October. Help us turn shared responsibility into shared practice.
We have work to do, together.
About the Author
Curtiss Barnes is CEO of 1EdTech, a non-profit technology standards and edtech education and research organization serving the learn and work ecosystem worldwide.
