Notifications
Clear all
Topic starter
10/06/2026 11:04 pm
TL;DR: Canvas was breached because an authenticated subject could perform high-trust actions through support and content workflows, exposing usernames, email addresses, course names, enrollment data, and messages, according to EnforceAuth's analysis of Instructure's incident. The real lesson is that authentication can work perfectly while authorization still leaves a tenant-scale blast radius.
NHIMG editorial — based on content published by EnforceAuth covering the Canvas incident and multi-tenant authorization risk: The Thesis, The Claim, The Ask
Questions worth separating out
Q: What breaks when authentication is correct but authorization is weak in SaaS platforms?
A: A platform can verify identity correctly and still let the wrong subject perform high-impact actions.
Q: Why do multi-tenant SaaS apps need decision-centric authorization?
A: Because tenant safety depends on the action decision, not only on the identity proof.
Q: How do security teams know if authorization is actually working?
A: They should be able to prove, quickly, why a privileged action was allowed, who requested it, which tenant it applied to, what policy version applied, and when the grant expired.
Practitioner guidance
- Map every high-trust support path Inventory support reads, admin actions, export functions, token issuance, and content changes across your SaaS estate.
- Move privileged decisions into a central policy layer Pull the highest-risk authorization checks out of scattered application code and into a runtime policy decision point.
- Require decision logs for every privileged action Make ticket reference, tenant identity, approved purpose, grant expiry, and policy version part of the audit record for each sensitive action.
What's in the full article
EnforceAuth's full article covers the operational detail this post intentionally leaves for the source:
- A worked breakdown of the six Canvas attack steps and where each policy decision would have intervened.
- Policy-as-code examples showing how support reads, token issuance, and content changes can be evaluated at runtime.
- The discovery scanner workflow that maps where authorization logic lives across a codebase.
- A 30-day proof-of-value scope for testing one policy domain against a representative application.
👉 Read EnforceAuth's analysis of the Canvas authorization failure in multi-tenant SaaS →
Canvas and multi-tenant SaaS authorization risk: what teams missed?
Explore further
12/06/2026 4:52 am
Authentication is no longer the control that decides tenant safety. The Canvas incident shows that identity systems can authenticate a subject correctly and still fail at the point that matters most: what that subject can do. In multi-tenant SaaS, the real control surface is the runtime authorization decision, not the login ceremony. Practitioners should treat this as an identity governance problem, not only an application bug.
A few things that frame the scale:
- 72% of organisations have experienced or suspect they have experienced a breach of non-human identities, according to The 2024 ESG Report: Managing Non-Human Identities.
- Two-thirds of enterprises have endured a successful cyberattack resulting from compromised non-human identities, with a quarter encountering multiple attacks, according to Oasis Security & ESG.
A question worth separating out:
Q: Who is accountable when support workflows expose customer data across tenants?
A: Accountability sits with the organisation that designed the workflow, the team that owns the policy, and the operator who executed the action. In regulated environments, auditors and customers will expect the business to show purpose, approval, and tenant separation for every privileged action. Without that chain, responsibility becomes disputed even when the access was technically authenticated.
👉 Read our full editorial: Canvas exposed the authorization gap in multi-tenant SaaS
