Canvas breach shows why identity risk now spans every identity

At a glance

What this is: This is Delinea’s analysis of the Canvas breach, showing how stolen SSO credentials, captured MFA codes, and abused NHIs let attackers operate inside trusted access paths long before the ransom demand surfaced.

Why it matters: It matters because identity teams must govern what happens after authentication, especially where SaaS trust, vendor credentials, and machine identities create attack paths that traditional login controls do not contain.

By the numbers:

• ShinyHunters stole 3.65 terabytes of student and faculty data from Canvas.
• The attackers exfiltrated approximately 275 million records before the ransom demand appeared.
• The platform was trusted by more than 8,800 educational institutions worldwide.
• Delinea Labs says NHIs now outnumber human identities by approximately 52:1 in enterprise environments.

Context

Canvas is not just a single application breach. It is a case study in how shared SaaS access, delegated trust, and machine identities can extend attacker reach after the first credential is captured. The identity risk surface now spans people, service accounts, automation, and AI-connected access paths.

Delinea’s account places the breach in a familiar pattern. The attackers did not need a software flaw to get in, and they did not need a new exploit to keep moving. Once access was trusted, the control problem shifted from authentication to authorization and from perimeter login checks to continuous governance.

For identity teams, the lesson is structural: if privileged access is still treated as a one-time login event, the programme is already behind the threat model.

Key questions

Q: What breaks when attackers can steal MFA session tokens?

A: MFA stops being the control point once the attacker has a valid token or cookie. The real failure is that the session is trusted after authentication, so the attacker can reuse access without reentering credentials. Organisations need to treat token replay as an identity event, not just an endpoint or phishing problem.

Q: Why do SaaS breaches still happen even when the vendor has built security controls into the platform?

A: SaaS breaches often occur because the weak point is customer-side control execution, not the platform itself. Stolen credentials, missing MFA, excessive permissions, and manual handoff gaps can all expose sensitive data. The vendor may provide the security options, but customers must configure and enforce them correctly to reduce the attack surface and limit unauthorized access.

Q: What are the signs that non-human identity governance is starting to slip?

A: Warning signs include reliance on manual upgrade paths, ad hoc secret handling, and fragmented access management across tools and environments. The article mentions caveats, dispatch limits, SSO support, and automated update channels, all of which point to the need for controlled operational discipline. When teams cannot explain how identities are provisioned, updated, and constrained, governance is already weaker than it should be.

Q: How should security teams handle vendor access that can reach production data?

A: Treat vendor access as a governed identity lifecycle, not a static trust decision. Revalidate scopes, offboard unused grants, and apply the same review standard to third-party credentials that you apply to privileged internal accounts. If a vendor can reach production data, its access should be observable, bounded, and revocable.

Technical breakdown

How voice phishing became durable access

Voice phishing, or vishing, works because the attacker does not need to defeat authentication technology directly. They persuade a user to hand over SSO credentials and MFA codes in real time, then add their own device so the next challenge is satisfied by the attacker’s device rather than the legitimate user’s. That turns a one-time compromise into recurring access. In this case, the attacker then appeared as an authorised user, which meant downstream controls saw normal login behaviour. The architectural weakness is not just deception. It is trust in enrolment and device registration paths that assume the enrollee is legitimate.

Practical implication: separate device enrolment from simple credential possession and require stronger control over MFA registration events.

Why NHI abuse extends the blast radius

Once inside, attackers often move through non-human identities such as service accounts, automation pipelines, OAuth grants, and API tokens because those identities are designed for persistence and system-to-system trust. They are frequently over-permissioned, rarely recertified in real time, and often invisible to the people managing user access. That makes them ideal for lateral movement and privilege expansion after a human credential has been compromised. The real issue is not that NHIs exist. It is that they are usually governed as static infrastructure rather than as identities with their own lifecycle, ownership, and access scope.

Practical implication: inventory and govern NHIs as first-class identities, not as hidden technical dependencies.

Why continuous authorization matters after login

Traditional IAM assumes authentication is the critical checkpoint. This breach shows the stronger control is continuous authorization, where access remains conditional on current context, purpose, and risk after the session begins. That matters because captured credentials, vendor grants, and long-lived tokens can all be used by an attacker who already looks legitimate. In a SaaS environment, the question is not only who logged in, but what they can still reach, register, export, or alter while authenticated. Once the attacker is operating inside accepted trust boundaries, the missing control is runtime governance, not another login prompt.

Practical implication: shift control design from initial login success to post-authentication entitlement enforcement and session governance.

Threat narrative

Attacker objective: The attackers aimed to gain persistent trusted access, exfiltrate large volumes of student and faculty data, and use that leverage for extortion.

1. Entry began with voice phishing and credential-harvesting sites that captured SSO credentials and MFA codes from legitimate users.
2. Credential access was extended when the attackers registered their own devices for ongoing authentication, allowing them to appear as authorised users.
3. Escalation occurred as the attackers moved through the environment, including non-human identities and trusted SaaS connections, to expand reach without triggering obvious human-facing controls.
4. Impact followed when they exfiltrated approximately 275 million records, stole 3.65 terabytes of data, and replaced the Canvas login page with a ransom demand.

NHI Mgmt Group analysis

Continuous authorization is now the decisive control boundary: the old assumption that authentication is the main gate no longer holds when attackers can register devices and operate as accepted users. That shift moves governance from login-time checks to the ability to limit what an identity can do after access begins. Organisations that still treat authentication as the finish line are governing yesterday’s threat model.

Vendor trust without lifecycle review creates identity drift: delegated SaaS access, OAuth grants, and API tokens become part of the same attack surface as internal accounts the moment they are trusted to reach production data. In this case, the attack did not require code exploitation, only trusted credentials and stale access relationships. The implication is that third-party access must be governed as a living identity problem, not as a one-time onboarding event.

Non-human identities are the hidden multiplier in SaaS compromise: service accounts and automation paths often sit outside the visibility model used for human IAM, yet they are exactly what attackers use to expand access after initial compromise. Ephemeral credential trust debt: the longer machine credentials, tokens, and grants persist without review, the more attacker leverage accumulates in the environment. Practitioners should treat NHI governance as a primary control plane, not an afterthought.

Identity risk now spans every identity, not every login: the Canvas case shows why people, vendors, service accounts, and automated access channels must be governed together. That does not mean collapsing them into one policy. It means recognising that the attacker’s path crosses all of them, so programme ownership must do the same. Security leaders should re-evaluate whether their current access model can still distinguish trusted from compromised behaviour once a session is active.

The breach validates OWASP-NHI and runtime governance as operational priorities: overprivileged NHIs, long-lived access paths, and weak offboarding are no longer edge cases in SaaS estates. They are the mechanisms that let attackers stay inside after the first phish succeeds. The practical conclusion is that identity programmes need real-time enforcement, not periodic reassurance.

What this signals

Identity risk now follows the session, not the login: programme owners should assume that once a credential is captured, the attacker’s objective is to stay within accepted trust boundaries long enough to register devices, reach data, and move through connected systems. That shifts emphasis from blocking the first sign-in to constraining what an identity can still do after sign-in.

Ephemeral credential trust debt: the longer credentials, tokens, and delegated grants remain valid without review, the more value they accumulate for an attacker. Security teams should re-centre governance on the lifespan and revocability of access rather than on whether access was originally approved.

The practical question is whether current identity controls can still separate legitimate from compromised behaviour once an attacker has inherited trust. If the answer depends on periodic review alone, the programme is too slow for the environment it now protects.

For practitioners

• Map every identity path into production data Build a current inventory of human users, service accounts, delegated vendor access, OAuth grants, and automation pipelines that can reach production systems. The goal is to see where trust is inherited rather than directly owned.
• Tighten MFA device registration controls Require stronger checks before a new device can be enrolled, especially when the request follows password reset, helpdesk contact, or unusual authentication patterns. Captured credentials should not be enough to bind a new device to the account.
• Review SaaS vendor credentials and token scope Re-certify every vendor-held access path to production data, including OAuth grants and API tokens, and remove permissions that exceed current business need. Treat onboarding-era trust as expired until revalidated.
• Move to continuous authorization for high-risk sessions Enforce runtime checks that can reduce or revoke access after authentication when context changes, rather than assuming a successful login is sufficient. This is especially important for privileged SaaS access and machine identities.
• Establish NHI ownership and offboarding rules Assign owners for service accounts, automation identities, and token-based access so they can be reviewed, rotated, or revoked when the workflow changes. Unowned credentials are the easiest to reuse after a breach.

Key takeaways

• The Canvas breach shows that identity compromise can persist well beyond the initial phish when device enrolment, delegated trust, and NHI access are not tightly governed.
• The article says attackers stole 3.65 terabytes of data and approximately 275 million records, which is enough scale to turn access governance into an operational resilience issue.
• The control that would have reduced attacker leverage is continuous authorization across every identity, including vendor credentials, automation, and service accounts.

Key terms

• Continuous authorization: Continuous authorization is the practice of rechecking access as a session unfolds instead of trusting a single login decision. It matters for AI workflows because the request, context, retrieved data, and downstream action can all change between prompt and execution, making static approval too blunt.
• Non-Human Identity (NHI): A digital identity assigned to a non-human entity such as a software application, service account, API key, bot, machine, or AI agent that enables it to authenticate and interact with systems without direct human involvement. NHIs now outnumber human identities in most enterprises by 25 to 50 times.
• Device Registration Abuse: Device registration abuse occurs when an attacker uses stolen credentials or weak enrolment checks to bind their own device to a victim account. Once the device is trusted, future authentication can succeed without triggering obvious anomalies, turning a one-time compromise into persistent access.
• Delegated Access: Delegated access is permission granted to one identity to act on behalf of another user, service, or system. In NHI environments, this usually appears in OAuth-connected apps and automation tooling. It is powerful, but it must be tightly scoped and reviewed because it can persist long after the original business need ends.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.