Canvas breach shows why SaaS integrations are NHI risk

At a glance

What this is: This is an independent analysis of the Canvas breach and its key lesson: SaaS integrations behave like non-human identities and can become the real attack path.

Why it matters: It matters because education and other SaaS-heavy environments need to govern OAuth tokens, service accounts, and legacy auth gaps as part of core IAM and NHI risk management.

By the numbers:

• Instructure's April 2026 breach may have affected up to 275 million users.
• The company behind Canvas serves more than 8,000 universities and schools.

👉 Read Silverfort's analysis of the Canvas breach and SaaS identity risk

Context

Canvas is not just a learning platform. In modern education environments, it sits inside a web of OAuth tokens, API keys, service accounts, and legacy authentication paths that function as non-human identities and often outlive the controls around them. The Canvas breach shows how quickly a vendor incident becomes an identity governance problem for the institution.

The central lesson is that SaaS integrations are part of the attack surface, not just the software stack. Instructure's April 2026 incident is a reminder that attackers often target the path with the broadest access and weakest oversight, which is exactly where NHI governance usually breaks down. That is a typical failure pattern in heavily integrated environments, not an edge case.

Key questions

Q: What breaks when SaaS integrations are not governed as non-human identities?

A: Teams lose visibility into who or what can reach connected systems, and attackers can use trusted credentials to move through those integrations without triggering normal human-account controls. The practical failure is blast radius, not just access. One over-scoped token or service account can expose multiple downstream platforms, especially when ownership, rotation, and review are missing.

Q: Why do service accounts and OAuth tokens increase breach impact in cloud environments?

A: Because they often carry standing access to more than one system and are trusted by the platforms they connect. That makes them ideal for lateral movement after compromise. In cloud and SaaS environments, the issue is not only that these identities exist, but that their scope is usually broader and their monitoring weaker than human access.

Q: How do security teams know if integration credentials are operating outside their intended scope?

A: Look for access to systems the credential has never touched before, unusual authentication times, protocol mismatches, and data requests that do not match the integration's normal business function. Those are strong indicators that a token or service account has been reused or repurposed. Baseline both network paths and application behaviour.

Q: What should institutions do in the first 72 hours after a vendor-linked identity breach?

A: Contain the exposed credentials, disable or rotate affected tokens, and map every downstream system the integration can reach. At the same time, preserve logs, notify legal and privacy teams, and determine whether student or employee data was accessible. The first 72 hours are about scope control and evidence preservation, not perfect root-cause certainty.

Technical breakdown

Why SaaS integrations behave like non-human identities

OAuth tokens, API keys, and service accounts are machine-usable credentials that act on behalf of a system rather than a person. In practice, they inherit access from the application they connect, but they often bypass the visibility, MFA expectations, and review cycles used for human accounts. That makes them a distinct governance class inside IAM. When an attacker compromises a vendor integration, they are not just stealing a credential. They are inheriting downstream trust relationships across connected systems. Practical implication: map every integration credential to an owner, scope, and rotation policy.

Practical implication: Treat every SaaS integration credential as an identity with lifecycle and access-review requirements, not as a static technical setting.

How standing privilege and legacy auth widen blast radius

Standing privilege means a credential keeps access continuously instead of being granted only for a task window. In education IT, that can include long-lived access to Salesforce, IdP links, or student data systems, sometimes with no MFA on legacy protocols such as NTLM, Kerberos, or LDAPS. When attackers obtain valid credentials, they do not need to exploit code. They use the trusted path and move laterally through authorized integrations. That is why the blast radius is usually larger than the original compromise. Practical implication: identify where authentication still depends on protocol exceptions and reduce standing access first.

Practical implication: Prioritise removal of standing privilege and legacy-auth exceptions before they turn a single compromise into a multi-system breach.

Why post-authentication monitoring matters more than login alerts

Traditional identity controls often focus on whether a login succeeded, but NHI abuse usually starts after authentication. Once an OAuth token or service account is accepted, the attacker can query data, pivot into adjacent systems, or create persistence without triggering a password-based alert. That is why Identity Threat Detection and Response and access intelligence matter: they observe unusual access times, protocol mismatches, and new system paths. The failure mode is not authentication failure. It is trusted activity that looks normal at the login layer but abnormal in context. Practical implication: tune detections for token use, scope drift, and unusual downstream access.

Practical implication: Build detection around post-authentication behaviour, because valid credential use is where most NHI abuse hides.

Threat narrative

Attacker objective: The objective is to reuse trusted integration paths to reach production education data at scale without needing to break the platform directly.

1. Entry via compromised SaaS integration credentials, including OAuth tokens or service accounts with downstream access.
2. Escalation through over-scoped trust relationships and legacy authentication paths that do not enforce modern MFA controls.
3. Impact through lateral access to Canvas production data, including private messages, names, email addresses, and student ID numbers.

Breaches seen in the wild

• Dropbox Sign breach — compromised Dropbox Sign service account exposed API keys and OAuth tokens.
• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

The real control gap is not SaaS access itself but ungoverned trust between systems. Education platforms increasingly depend on OAuth-linked services, identity providers, and downstream databases. When those connections are not inventoried and reviewed as non-human identities, the institution inherits hidden access paths it cannot explain. Practitioners should treat every integration as an identity relationship that must be owned, scoped, and periodically revalidated.

Identity blast radius is now the decisive risk metric for integrated environments. The question is no longer whether a vendor can be breached, but how far a valid credential can travel once the first boundary is crossed. That shifts the security conversation from perimeter defense to access containment, protocol hardening, and NHI lifecycle governance. Teams should measure how much data any single integration can reach before a compromise becomes reportable.

Credential abuse in SaaS ecosystems validates NHI governance as a board-level control, not a niche technical concern. When private messages and student records are exposed through trusted integrations, the downstream institution inherits both operational and regulatory pressure. That makes NHI visibility, rotation, and offboarding part of business resilience rather than optional hygiene. Practitioners should elevate these controls into governance reporting and incident preparation.

Legacy protocol exceptions are where modern identity programs lose control. Many environments have MFA for cloud apps but still rely on older authentication flows for operational continuity. Attackers exploit that gap because the trusted path is easier than exploiting software. Teams should inventory every exception path and eliminate the ones that let service identities bypass current control standards.

From our research:

• 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures, according to Ultimate Guide to NHIs.
• Only 5.7% of organisations have full visibility into their service accounts, which is why vendor-linked integrations remain hard to govern at incident speed.
• That visibility gap is explored further in NHI Lifecycle Management Guide, which helps teams build inventory, rotation, and offboarding discipline before the next breach.

What this signals

Identity blast radius should become a standing metric in education and SaaS-heavy environments. If a vendor-linked credential can reach multiple systems without reauthorization, the institution has already lost control of the trust boundary. That is why integrating inventory, ownership, and access scope into the identity programme matters more than counting logins.

With 80% of identity breaches involving compromised non-human identities such as service accounts and API keys, the security problem is no longer abstract. Programmes that still treat integrations as infrastructure details will keep missing the path attackers actually use.

The next maturity step is to align identity governance with incident operations. Teams need a way to answer, in hours rather than days, which integrations exist, what they can reach, and how quickly they can be revoked when a vendor-linked compromise occurs.

For practitioners

• Inventory all SaaS integration identities Build a live register of OAuth tokens, API keys, service accounts, and delegated app connections that reach student data, IdPs, or CRM systems. Assign each one an owner, business purpose, expiry date, and rotation cadence. If you cannot name the owner, treat the credential as ungoverned.
• Reduce standing privilege in connected systems Remove persistent access where a task-scoped model will work, and review every integration that can reach multiple downstream systems without reauthorization. Focus first on paths that bridge Canvas, Salesforce, identity providers, and student information systems. This is where a single compromise becomes a broad breach.
• Extend MFA to legacy authentication paths Do not stop at cloud app MFA. Map the protocols and services that still allow access through exceptions such as NTLM, Kerberos, or LDAPS, then wrap or replace them so they no longer bypass modern verification. Legacy exceptions are a common route around your strongest controls.
• Tune detections for post-authentication abuse Use identity threat detection and response rules that watch for unusual access times, protocol mismatches, new downstream targets, and OAuth token behaviour that diverges from baseline. Login success is not enough. The useful signal is what the identity does after it authenticates.
• Prepare notification and evidence workflows now Align security, legal, and communications teams on what must be documented when a vendor-linked identity breach affects student or employee data. Institutions should pre-stage evidence collection, contract review, and notification templates so response time does not depend on ad hoc coordination during the incident.

Key takeaways

• SaaS integrations are part of the identity plane, so governance failures in OAuth tokens and service accounts can create the real breach path.
• The scale of the problem is amplified by poor visibility and slow remediation, which leaves compromised secrets valid long after detection.
• Institutions should respond by inventorying integration identities, removing standing privilege, and building post-authentication detection around actual behaviour.

Key terms

• Non-Human Identity: A non-human identity is any credentialed entity that acts on behalf of software rather than a person, including service accounts, API keys, tokens, and certificates. In practice, these identities often carry broad trust and weak lifecycle controls, which makes them a common breach path when they are not inventoried and governed.
• Identity Blast Radius: Identity blast radius is the amount of systems, data, and privileges reachable through one compromised identity or integration. It is a practical way to measure how far a token, service account, or delegated connection can travel before containment fails. Lowering blast radius is a core objective of NHI governance.
• Post-Authentication Abuse: Post-authentication abuse happens when an attacker uses valid credentials to perform actions after login rather than breaking authentication itself. For NHI environments, this often means abusing tokens, service accounts, or delegated access to query data, move laterally, or establish persistence while appearing legitimate to basic login controls.
• Standing Privilege: Standing privilege is access that remains continuously available instead of being granted only when needed for a specific task. It creates avoidable risk because compromised credentials stay useful for longer and can reach more systems than necessary. Reducing standing privilege is one of the fastest ways to shrink breach impact.

Deepen your knowledge

SaaS integration governance and non-human identity lifecycle control are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If your environment relies on interconnected education systems or other high-trust SaaS links, it is worth exploring.

This post draws on content published by Silverfort covering the Canvas breach and its identity security implications. Read the original.