Blackboard Finally Sets an End Date for LTI 1.0/1.1

Every Tuesday I show up to Blackboard LMS Office Hours mostly out of habit at this point, the way you check a weather app you don’t fully trust. Most weeks it’s routine maintenance notes and a demo or two. August 25th was not most weeks. Wade Weichel from Blackboard announced something a chunk of the admin community has been quietly waiting on for a couple of years: a real, dated retirement plan for LTI 1.0 and 1.1.

I pulled the slide deck Blackboard shared during the session and sat through the recording twice, once for the announcement and once for the Q&A, because the Q&A is where the actually useful information tends to live. Here’s what’s happening, what it means for your institution, and what the slides don’t tell you that the office hours crowd asked about directly.

The timeline gives you runway, but it is not infinite. Blackboard is retiring LTI 1.0 and 1.1 in three phases. Right now through the end of 2026, nothing changes functionally, every tool keeps working and you can still register new LTI 1.0/1.1 integrations. Starting January 1, 2027, however, that registration door closes. Existing tools keep launching normally, and instructors can still create new course links against them, but no new 1.0/1.1 tools get added to the system. Then on September 30, 2027, Blackboard flips the switch and turns off everything still running on the old protocol. Any tool that hasn’t upgraded to LTI 1.3 by that date simply stops working, full stop, no grace period. That’s a little over a year of runway from the announcement, which is generous by vendor standards, but Wade was explicit that starting the vendor conversations now rather than in month eleven is the difference between a manageable project and a scramble.

This is not the Canvas breach, and Blackboard wants that distinction on the record. With Instructure’s LTI-adjacent security incident with the ShinyHunters extortion group still fresh (I covered the vendor accountability angle and the admin action items in a two-part series earlier this year), it was inevitable someone in office hours would ask whether Blackboard environments carry the same exposure. Wade’s answer was direct: no. Blackboard’s LTI 1.0/1.1 implementation has always been limited to outbound single sign-on and, for 1.1, score return. There’s no two-way web service layer sitting on top of it. Instructure, by contrast, built out a full create-read-update-delete web services layer on that same weak LTI 1.0/1.1 security model years ago, which is a meaningfully different risk surface. Wade also connected this to LTI history I hadn’t heard framed this way before: LTI 2.0 tried to build that same kind of expanded web-services model, it also had poor security, and it’s actually part of why the 1EdTech community scrapped it and built LTI 1.3 from scratch. So the retirement isn’t reactive panic dressed up as a security initiative. It’s Blackboard closing a gap that 1EdTech itself flagged when it stopped certifying LTI 1.0/1.1 back in 2019. Seven years is a long runway to have not acted, and Wade said as much himself. Credit where it’s due, though: better seven years late than never, and the actual risk profile here is lower than the Canvas comparison implies.

Developers get two migration paths, and one of them has zero rollback. For tool providers, the recommended route is an in-place upgrade: register your LTI 1.3 tool at the same domain as the existing 1.1 registration, Blackboard detects the overlap and offers to migrate all existing course links automatically, and instructors never have to touch anything. The alternative, when in-place upgrade isn’t technically feasible, is a clean new LTI 1.3 registration with instructors manually recreating links. Wade’s warning here is worth repeating word for word in spirit if not in quote: the in-place upgrade is a one-way operation. There is no rollback. He mentioned Blackboard has already seen cases where an institution ran the upgrade assuming the tool supported it, the tool didn’t, and every existing link broke with no way back. Test this in a non-production environment before you touch anything live. That’s not boilerplate caution, that’s a documented failure mode.

The office hours Q&A surfaced the parts that actually relevant for planning. A few things came up in discussion that aren’t in the slide deck at all.

I asked directly about the instructor-facing “add your own LTI tool” feature that exists in some course structures today, since that workflow depends entirely on LTI 1.1’s lightweight registration model. Wade confirmed it: that feature goes away. LTI 1.3 exposes significantly more personal data and web service access than 1.1’s simple SSO handshake, so letting an individual instructor self-register a tool without institutional review isn’t a model that survives the transition. If your institution leans on self-service tool registration anywhere, that workflow needs a governance conversation now, not next August.

Another attendee raised a scenario worth watching if you run any Turning Technologies-style clicker or polling integration: her institution’s vendor is routing its LTI 1.3 upgrade through a third-party integrator, Ed Link, rather than upgrading the existing connection directly. Wade’s read was that this is fine as a pattern as long as you understand what data the integrator touches, but it does mean an extra vendor in your security review chain that wasn’t there before. If your tool providers start mentioning integrators you’ve never vetted, ask what they’re storing.

One attendee asked the question every admin has been quietly concerned about when facing issues like this. If a tool shows zero placements and zero usage in the LTI provider table, can you just delete it? Wade’s answer was reasonably cautious: deletion is destructive, and the utilization numbers in that admin panel table shouldn’t be fully trusted, but placement counts should be accurate, and zero placements means nobody can be launching it. His recommendation, and mine too, is to disable rather than delete and see if anyone surfaces. Scott Hurrey who leads the Blackboard Illuminate team also confirmed better LTI usage and version reporting will come to Illuminate in the next few weeks, including the ability to filter directly on LTI version, though he flagged it involves a change to how tools are keyed in the tool table that could break existing custom reports. If you’ve built anything on top of the current tool table structure, that’s worth keeping an eye on.

On process, Blackboard is explicitly modeling this after the Building Block retirement process: this process included tracking vendor upgrade plans, crowdsourced from the admin community, and maintained on the community site. Given how genuinely useful that resource was during the Building Block transition, I’d call this the single smartest thing Blackboard is doing here procedurally. Contribute to it when it goes live. The whole point is that Blackboard doesn’t have relationships with every vendor in your tool inventory, but collectively the admin community does.

My take. This is the right call, executed at a reasonable pace, and Blackboard is being unusually direct about the fact that the upgrade path has a real failure mode if you don’t test it. What I’d flag as the actual risk here isn’t the September 2027 deadline, it’s vendor responsiveness. We’ve been here before with Building Blocks: the institutions that struggled weren’t the ones who didn’t understand the technical requirement, they were the ones whose tool vendors dragged their feet until the deadline was uncomfortably close or lacked the tool set within the application to move. Start your LTI tool inventory review this week, not this semester. Administrator Panel >> Integrations >> LTI Tool Providers will show you which tools are still on 1.0/1.1 today, and a version flag is coming in the September release to make that even more obvious. Email your vendors now, ask specifically whether they support in-place upgrade or require link recreation, and get that answer in writing. If the answer is link recreation, start planning your instructor communication immediately, because that is the part of this transition that actually touches your end users and the part most likely to generate support tickets if it’s rushed.

Technically Yours,

The Blackboard Guru