Summary:
- LTI 1.3 keys: nothing to rotate, see below.
- Manual API keys: Instructure has given us no indication that rotation is required. If your security team would like to rotate as a precaution, we offer two paths: switching to the inherited API key (preferred) or reissuing the manual key. Both require a one-time educator re-authentication.
- For the original incident write-up, see our May 1st Canvas incident article.
Why LTI 1.3 keys are not on the rotation list
LTI 1.3 is built on asymmetric cryptography: each side of the integration holds its own private signing key and shares only the corresponding public key with the other.
In practice, Canvas signs launches with Canvas's private key, and we verify them using Canvas's public keys. When we make API calls back to Canvas (for grades, rosters, deep linking), we sign those with our private key, and Canvas verifies them using our public keys. Each side fetches the other's public keys live from a JWKS URL.
Our private key has never lived on Canvas infrastructure, so a Canvas-side breach cannot expose it. The only thing Canvas holds from us is our public key, which is by design public information.
A few things follow:
- Rotating our LTI 1.3 keypair would publish a new public key for Canvas to fetch, but no attacker held the matching private key: nothing would be mitigated.
- We rotate our LTI 1.3 keypairs monthly as standard practice, independent of this incident.
- The client_id, deployment_id, and issuer URL exchanged at setup are tenant identifiers, not secrets: they are not in scope for rotation.
Manual API keys: optional precaution
Manual API configuration uses a Canvas-issued OAuth credential: a client_id and secret your admin generated in Canvas and shared with us. That secret lives in Canvas, so unlike the LTI keypair, it sits within the scope of credentials a Canvas-side incident could plausibly touch.
Instructure has given us no indication that rotation of these credentials is required at this stage. If your security team would like to rotate as a precaution, you have two options.
A note before deciding: Both rotation paths pause course data synchronisation, including scheduled grade syncs, in every course with FeedbackFruits activities. Recovery happens per course, only once an educator in that course opens an activity and re-authorises. There is no central re-enable we can run on our side. Given that Instructure has given us no indication this rotation is needed, we'd treat it as a security-team judgement call rather than a default precaution.
Option 1 (preferred): switch to the inherited API key
Now that Instructure has restored the inherited API key flow, this is what we recommend going forward. It removes credential management from your admins entirely: there is no client_id or secret for you to exchange with us. The credentials live on Canvas's side, and Instructure refreshed them globally as part of their incident response.
To set up, follow the steps in Configuring the API for Canvas under ‘Inherited configuration’. Find and enable the key with ID 170000000002380.
Option 2: reissue the manual API key
If staying on manual configuration is preferred:
- Your Canvas admin creates a new Developer Key in Canvas, see Configuring the API for Canvas.
- Send the new client_id and secret to your Partner Success Manager through your preferred secure channel. Please do not send credentials over plain email or chat.
- Do not disable the existing key yet. We need to swap the new credentials in on our end first; disabling early would cause downtime for your educators.
- We confirm the swap is live.
- Your admin disables (or deletes) the old Developer Key in Canvas.
Educator re-authentication (applies to both options)
Either path changes the API credentials FeedbackFruits uses against your Canvas tenant, so educators in courses with FeedbackFruits activities will be prompted once on their next launch to re-grant permissions to FeedbackFruits. Data synchronisation, including scheduled grade syncs, resume after the first educator re-authentication in that course.
On Instructure/Canvas side, for completeness
Canvas's platform signing keys. They publish roughly three keys at a time and rotate monthly. Beyond that normal monthly rotation, we have not seen any indication that Canvas signing keys were retired or replaced as part of incident response, and we are working under the assumption that those private keys were not part of the breach.
Canvas-issued user OAuth tokens. When Instructure rotated our inherited API key on May 1st, the user OAuth tokens issued under it were invalidated; the educator re-authentication flow described above is Canvas reissuing fresh tokens against the new credential. We expect the same behavior when an old manual key is disabled in step 5 of Option 2: Canvas invalidating the tokens issued under it, and educator re-authentication produces fresh ones.
How to request a rotation or migration
Email your Partner Success Manager and tell us whether you would like Option 1 (migrate to inherited) or Option 2 (reissue manual key). For Option 2, please follow the sequencing above and do not disable the old key before we confirm the swap.