Developing Impact of Data Breach on Australian Schools, Universities & Educational Institutions.

Instructure / Canvas LMS Cybersecurity Incident

Update: 12 May 2026 (12:30pm AEST)

Vendor reports negotiated resolution.

Instructure CEO Steve Daly issued a community statement at approximately 11:00am AEST on 12 May 2026, confirming that Instructure reached an agreement with the unauthorised actor. Per the statement: the data was returned to Instructure; Instructure received digital confirmation of data destruction (shred logs); Instructure has been informed that no customers will be extorted as a result of this incident, "publicly or otherwise"; and the agreement covers all impacted customers. Individual institutions do not need to engage with the actor.

1. What is new

Three additional points from Instructure's incident-update page that institutions should note:

• Notification posture clarified. Per Instructure: institutions that have not been contacted directly by Instructure have not, on current evidence, been identified as having data involved. Direct contact is the trigger; absence of contact is the (provisional) answer.

• Customer webinar flagged. Instructure has indicated a customer webinar with company leadership for approximately 13 May 2026, run across multiple time zones, covering the incident and the hardening work undertaken. We recommend institutional security and IT leadership register and attend the time-zone-appropriate session.

• Forensic timeline anchored. The independent e-discovery review of the data involved is, per Instructure, expected to take "some weeks" to complete. The forensic-summary report is the next milestone for this advisory series.

2. What this does not establish

Instructure's statement is a vendor representation, not an independently verified forensic outcome. The following limits apply:

• Assurances from an extortion actor that data has been deleted cannot be independently verified. Instructure itself acknowledges that "there is never complete certainty when dealing with cyber criminals."

• The statement does not disclose the terms of the agreement, the chain of custody for the returned data, or the method used to validate deletion.

• The extortion-as-a-service caveat in our 8 May guidance has not been retired by the vendor statement. Third-party approaches referencing this breach remain foreseeable.

• The forensic-summary report Instructure committed to publishing has not yet been released.

3. What this changes for institutions

The immediate publication risk has receded. The structural exposure has not. The customer-side technical actions and the regulatory and communications guidance in our 8 May and 11 May updates remain operative without amendment.

Note on vendor guidance. Instructure's incident-update page states it is "not recommending broad new customer-side remediation" based on the 7 May activity, unless Instructure communicates directly with a specific customer. Our position is more conservative. The 8 May credential, integration, and monitoring actions were issued in response to the post-7 May intrusion picture and remain proportionate until forensic detail (IOCs, TTPs) is published.

4. Posture

We anticipate this being the final dated update in this advisory series, conditional on the vendor's forensic-summary report or any subsequent disclosure not changing the picture materially. We will reopen the advisory if that occurs.

5. Vendor-side developments: where to watch

• status.instructure.com for operational updates.

• instructure.com/incident_update for the incident hub, including the 12 May CEO statement and the forthcoming forensic-summary report.

——————————————————————————————————————

Update: 11 May 2026 (1:00pm AEST)

Vendor posture restored. Customer posture sustained.

Instructure has brought Canvas fully back online and identified the access pathway as a vulnerability in its Free-For-Teacher environment. The 12 May extortion deadline has effectively been overtaken by events. Many institutions are now re-enabling Canvas on vendor advice. The customer-side technical actions issued on 8 May remain in force.

The investigation, both at the vendor and into the threat actor's intentions, is not concluded.

1. What has changed in the last 72 hours

1.1 The current picture in brief

• Canvas is fully back online as of Friday 8 May 2026 US time, late Saturday 9 May AEST. Instructure has confirmed normal service and is advising customers that Canvas is safe to use.

• Instructure has launched a dedicated incident hub at instructure.com/incident_update, accompanied by a CEO statement acknowledging the disruption and committing to clearer communication going forward.

• The vulnerability has been identified as an issue in Instructure's Free-For-Teacher (FFT) environment, specifically related to support tickets. Instructure has temporarily shut down FFT while it completes a fuller security review.

• Vendor forensic position, per Instructure citing CrowdStrike as forensic partner: no evidence the threat actor currently retains access; no evidence data was taken during the 7 May activity specifically; the data classes from the original 29 April incident remain as previously stated (usernames, institutional email addresses, course names, enrolment information, and message content).

• Other Instructure products (Parchment, Mastery, Canvas Catalog) have been confirmed by the vendor as not impacted.

• Law enforcement engagement has been formally confirmed: the FBI, the U.S. Cybersecurity and Infrastructure Security Agency (CISA), and international partners.

1.2 What our SOC has observed independently

Our Security Operations Centre is reporting that Instructure no longer appears on the ShinyHunters public leak site. The listing that was visible during the active extortion window is no longer present.

We are reporting this observation only. We are not interpreting it. The absence of a listing has several possible explanations, none of which we are in a position to verify, and any inference about settlement, payment, or actor intent would be speculative. Institutions should treat the absence of a public listing as an observation, not as a resolution.

1.3 The 12 May deadline

The extortion deadline of end-of-day 12 May 2026 asserted by the actor in the 7 May defacement has effectively been overtaken by subsequent events. We have not observed a public release of data tied to that deadline, nor a renewed public threat referencing it. This does not constitute resolution of the underlying breach. It is one data point.

1.4 Re-engagement decision: where this leaves institutions

Our recommendation: cautious, conditional re-enablement. Institutions may cautiously and carefully re-enable their Canvas footprint, provided credentials, developer keys, integration secrets, and admin and local Canvas account passwords have first been confirmed as rotated, revoked, or otherwise protected. Re-enablement should not precede that work. The credential and integration actions in Section 2 of this update are the gating conditions, not optional accompaniments.

Many institutions across Australia and New Zealand are re-enabling Canvas on the vendor's advice. The Australian education community, including briefings coordinated via the MITIE Forum, has broadly aligned around a measured re-enablement posture rather than indefinite isolation.

Our position is unchanged in substance. Whether to re-enable Canvas, when, and under what conditions, is an institutional risk decision that rests with the Incident Response Team and the Executive on an Institutional basis. Several considerations apply:

• The vendor's containment claim is reasonable but not independently verifiable from the customer side. CrowdStrike's involvement raises confidence; it does not constitute customer-side assurance.

• The Free-For-Teacher vulnerability mechanism does not, in itself, foreclose other access pathways the actor may have used or retained. Indicators of Compromise (IOCs) and tactics, techniques, and procedures (TTPs) detail has been promised by Instructure but is not yet published.

• The customer-side technical actions issued on 8 May (see Section 2 of this update) remain operative regardless of whether Canvas is being turned back on or held offline. Re-enabling does not retire those actions.

2. Technical actions: customer-side actions remain in force

The technical action set issued on 8 May (see Section 2 of the 8 May update below) remains current, and is the precondition for re-enablement. Canvas should not be brought back online until the credential and integration items below have been completed, or are progressing in lockstep under a documented plan. We are not retiring any of those actions on the basis of Canvas being back online.

Before re-enabling Canvas, confirm the following have been completed, or are progressing in lockstep:

• Developer keys rotated or revoked (8 May Section 2.1).

• SSO configuration verified, including conditional access scoped to Canvas, legacy authentication disabled at the Identity Provider, and MFA enforced (8 May Section 2.2).

• Microsoft 365 and Teams integration scopes reviewed and reduced to least privilege (8 May Section 2.3).

• LTI tool and OAuth client inventory audited, unused apps removed (8 May Section 2.4).

• Admin and local Canvas user passwords rotated, MFA enforced on those accounts (8 May Section 2.5).

• Monitoring and alerting in place for Canvas service principal activity, SSO authentication events, and admin role changes (8 May Section 2.7).

The application-registration revocation option outlined at 8 May Section 2.6 remains available where leadership judges that the operational risk of continued authenticated vendor access outweighs the disruption of revocation. For most institutions, the practical decision is now between (a) re-enabling Canvas with the 8 May Section 2 hardening completed, or (b) holding Canvas offline pending the vendor's IOC and TTP disclosures.

3. ShinyHunters: do not engage

Re-emphasising guidance issued on 8 May. Do not engage with ShinyHunters under any circumstances. This applies whether your institution is contacted directly, indirectly, through a perceived intermediary, or via any unsolicited approach referencing the breach.

Two further points warrant repetition in this update:

• ShinyHunters operates as an extortion-as-a-service group. Any apparent settlement reached with the public-facing brand does not bind, and does not visibly identify, the underlying actors actually holding any exfiltrated data. Third-party extortion attempts referencing this breach are foreseeable and may continue to surface for months.

• Showing interest, even cautiously, is itself an indicator the actor will record. Institutions or individuals that engage, ask questions, or express willingness to negotiate are routinely added to follow-up target lists for repeat or third-party approaches.

Where an institution is contacted, the appropriate path is: do not respond, preserve the communication intact, notify your cyber insurer, notify your legal counsel, and notify law enforcement (the Australian Cyber Security Centre or the Australian Federal Police in Australia; CERT NZ or New Zealand Police in New Zealand).

4. Phishing remains the primary downstream risk

Independent of whether breach data is ultimately released publicly, expect Canvas-related phishing campaigns to continue. The structured data classes confirmed as exposed (names, institutional emails, student IDs, course enrolment, message context) are sufficient to support targeted impersonation campaigns directed at students, parents and carers, teachers, and administrative staff.

The user-education and service-desk guidance in the original report remains directly applicable, in particular:

• Pastoral and early-acknowledgement communications to communities (original report Section 5.4).

• Service-desk and HR scripts for handling concerned enquiries (original report Section 4.2 and Section 5).

• Age-appropriate awareness messaging for primary and secondary cohorts.

Treat the phishing exposure as the durable, long-tail consequence of this incident. It is independent of any negotiation outcome and is not retired by Canvas coming back online.

5. Governance and leadership notes

The governance actions issued on 8 May remain in effect. Two specific points for principals, boards, and senior leadership in this update:

• Re-engagement is a documented decision. Whether your institution re-enables Canvas immediately, in phases, or holds offline, that decision should be minuted, with the rationale and accepted residual risk recorded. This documentation is material to insurer engagement, regulatory assessment, and any subsequent review.

• Regulatory clocks have not stopped. The Notifiable Data Breaches assessment process under the Privacy Act 1988 (Cth) in Australia, and the equivalent process under the Privacy Act 2020 in New Zealand, continues to run on its own timeline. Vendor restoration of service does not change the assessment obligation. The principal-agent attribution point under both frameworks (8 May Section 3.5; original report Section 3.3) applies.

6. Vendor-side developments: where to watch

Two authoritative vendor sources to monitor:

• status.instructure.com for service availability and operational updates.

• instructure.com/incident_update for the dedicated incident hub launched 9 May 2026, containing the CEO statement, updated FAQs, and Instructure's commitment to publish a forensic-summary report. Instructure has stated it will post the next update within 48 hours of 9 May and will publish a forensics summary as soon as it is ready.

We will continue to monitor both sources and will incorporate confirmed material into subsequent dated updates above.

————————————————————————————————————————————————

Update: 8 May 2026 (1:00pm AEST)

Posture shift. The vendor-side picture has changed materially since the 30 April disclosure. The question institutions should now be asking is not whether data was exposed, but whether the vendor's systems remain compromised. We are recommending institutions move from a monitoring posture to an active containment posture.

1. What has changed in the last 24 hours

1.1 The new event in brief

At approximately 4:00pm Eastern Time on 7 May 2026, overnight Australian time, the threat actor defaced the Canvas login portals of approximately 320 educational institutions. The standard login page was replaced with a public extortion notice. The defacement was visible for roughly 20 to 30 minutes before being detected and removed. Affected portals now display a 'scheduled maintenance' message.

Instructure has confirmed via its status page that it is investigating. Canvas is currently offline (12:15pm AEST, 8 May 2026). The disruption is ongoing.

1.2 Why this is materially different from the 30 April disclosure

Instructure initially characterised the April incident as contained, with the underlying vulnerability addressed. The defacement event tells a different story. The threat actor was able to modify customer-facing login portals at scale after the vendor's initial remediation. This means the actor retained, or regained, access to Instructure's infrastructure.

Institutions should be putting this question to the vendor in writing: how deep is the infiltration into Instructure's systems, and what persistence remains? Until Instructure answers that question with forensic detail, institutions should not assume the vendor-side incident is resolved.

1.3 The extortion ultimatum

The defacement message set a deadline of end-of-day 12 May 2026 for affected schools and Instructure to negotiate a settlement. If that deadline passes without agreement, the actor states stolen data will be released.

Two points require emphasis:

• Individual schools have been invited to negotiate directly with the actor. This is strongly discouraged. Direct engagement with an extortion actor is operationally hazardous, is likely to conflict with cyber insurance policy terms, and may conflict with regulatory and law enforcement guidance. More importantly, it provides no enforceable guarantee that data is not subsequently released, resold, or used to extort the institution again. Any consideration of engagement must be coordinated through legal counsel, the institution's cyber insurer, and law enforcement.

• ShinyHunters is known to operate as an extortion-as-a-service group, running campaigns on behalf of other threat actors in exchange for a share of payment. Negotiating with the public-facing brand provides no assurance that the actors actually holding the data will honour any agreement.

1.4 Recommended posture shift

Given the active-intrusion picture now visible at the vendor, our partner Security Operations Centre is recommending institutions seriously consider revoking the Canvas application registration in their identity environment as a precautionary containment step. This means disabling Canvas's authenticated access into the institution's tenant entirely, rather than relying on credential rotation alone.

This is a stronger and more disruptive step than the rotation guidance in §4.1 of the original report. It is appropriate where the institution judges that the risk of leaving an authenticated pathway open to a vendor with unverified containment status outweighs the cost of operational disruption. The decision rests with the Incident Response Team and the accountable executive, informed by Business Continuity arrangements and the operational calendar. See §2.6 below for the full decision framework.

1.5 What this does not change

The data classes confirmed as exposed in the original incident remain the same: names, institutional email addresses, student IDs, and Canvas message content. The downstream phishing and impersonation risk profile in §3.1 of the original report is unchanged. The communications guidance in §5 of the original report remains operative. Regulatory clocks under §3.3 of the original report continue to run, and the principal-agent attribution point under both the Australian and New Zealand frameworks now applies with greater force given the recurrence.

2. Technical actions: for IT and security teams

The following are the most immediate customer-side technical actions our partner Security Operations Centre is advising. They are a sharpened, action-first restatement of the priorities in §4.1 of the original report, focused on the next 24 to 72 hours.

2.1 Developer keys

This one sits squarely with the customer institution. Identify every active Canvas developer key, rotate those that must remain active, and revoke those that are not in use. Most Student Information System (SIS) integrations will be affected. When rotating a key, make sure the change is reflected at both ends of the integration: the Canvas key value and the consuming SIS configuration. If only one end is updated, the integration will silently break.

2.2 Single Sign-On (SSO) configuration

For most institutions, SSO is the most secure part of the Canvas estate. Even so, it should not be assumed to be hardened without checking. Confirm the following:

• The federated trust relationship is intact and unchanged.

• Conditional access policies apply to the Canvas application.

• Legacy authentication paths are disabled at the Identity Provider (IdP).

• Multi-Factor Authentication (MFA) is enforced for all Canvas access, including service accounts and break-glass accounts.

2.3 Integrations: Microsoft Teams and others

The vendor holds responsibility for these integrations on the Instructure side. The customer's responsibility is to verify that the application registrations granting Canvas access into your Microsoft 365 tenant are not over-provisioned.

Apply the principle of least privilege: review consented Graph API permissions, remove any scopes the integration does not actively use, and document the reduced scope as the new baseline.

2.4 Application inventory: reduce the attack surface

Audit the full list of Learning Tools Interoperability (LTI) tools, external apps, and OAuth clients registered in your Canvas tenant. Remove anything not actively required. Each remaining integration is a credential pathway that must be treated as in-scope for the residual risk window.

2.5 Admin and local Canvas users

If your institution is on the confirmed affected list, rotate passwords for all admin and local (non-federated) Canvas users immediately and enforce MFA on those accounts.

If your institution has not yet been confirmed as affected, treat MFA enforcement on privileged and admin accounts as the highest-priority hardening action for this week regardless.

2.6 App-registration revocation: when to consider it

Following the 7 May defacement event (see §1.1 above), our partner SOC is recommending institutions seriously consider revoking the Canvas application registration in their identity tenant. This means disabling Canvas's authenticated access into the institution's Microsoft Entra, IdP, or source-system environment entirely, rather than relying on credential rotation.

This is a materially stronger step than rotation. Institutions should expect the following consequences:

• SSO into Canvas will break for staff, students, and integrated tooling.

• SIS, Microsoft Teams, and other downstream tools that authenticate via the Canvas app registration will stop working.

• A documented re-onboarding process will be required before access can be restored.

Revocation is appropriate where:

• The institution judges that operational disruption is preferable to leaving an authenticated pathway open into a vendor whose containment status is unverified.

• Canvas is not currently essential for assessment, examinations, or critical learning continuity in the next 72 hours, or where Business Continuity Plan arrangements can adequately cover that load.

• Senior leadership has explicitly accepted the disruption as an informed decision and the Incident Response Team has authorised the action.

This is not a default action and must not be taken without leadership authorisation. When access is eventually restored, all credentials, keys, and integration identities should be treated as new rather than reinstating the prior configuration.

2.7 Monitoring: what to collect and what to alert on

Where not already in place, prioritise ingestion of the following log sources into your Security Information and Event Management (SIEM) platform:

• Canvas service principal logins

• Canvas local (non-federated) user logins

• SSO authentication events for the Canvas application

Even basic detection rules provide meaningful coverage in this post-incident window. Alerts should cover: permission changes, new admin role assignments, logins from unexpected locations, and first-time service principal use.

Threat hunting should focus specifically on service principal activity. Unexpected token issuance, scope changes, or off-hours use are the leading indicators of credential abuse following a breach of this profile.

2.8 Data: where the residual risk concentrates

Of the data classes Instructure has confirmed as exposed, unstructured message content presents the greatest downstream risk. Structured fields (names, institutional emails, student IDs) are damaging in aggregate but bounded. Free-text messages between students, teachers, and staff routinely contain disclosures covering medical matters, welfare, behaviour, family, and assessment that the structured field list does not capture.

Communications planning, safeguarding review, and pastoral preparation should be calibrated specifically to the messaging dimension, not to the structured field list alone.

2.9 A note on student devices

Where multiple student devices at a single institution show signs of compromise traceable to this incident, segment-level isolation is a more effective response than working through devices one by one. It also makes better use of analyst time.

Institutions without asset-based isolation tooling should, with their security partner, pre-agree the threshold and authorisation pathway for isolating a student VLAN or network segment before the need arises. Acting first and raising a ticket second, under a clearly communicated heightened-environment posture, is appropriate where the alternative is delayed containment.

3. Governance and leadership actions: for principals, boards, and senior leadership

The technical response above is necessary but not sufficient. The governance dimension is where institutional reputation, regulatory posture, and community trust are shaped in the days following an incident. The following actions are directed at principals, governing bodies, and senior leadership.

3.1 Get in front of the messaging, in your own voice

We strongly advise communicating with your community sooner rather than later. The question is not whether your community will hear about this. It is whether they hear it first from you, in measured terms, or first from media coverage that may be less measured. An early, factual acknowledgement, even one that confirms tenant-specific impact has not yet been established, preserves trust and reduces speculation. A tested communication template is provided in §5.4 of the original report.

3.2 Formally invoke your Incident Response Plan

If you have not already done so, formally enact the plan:

• Convene the Incident Response Team.

• Confirm roles and responsibilities in writing.

• Set a standing update cadence, twice daily is recommended for the next 72 hours.

• Nominate a single accountable communications signatory.

A plan that is not formally invoked does not provide the structure it is designed to provide.

3.3 Ready your Business Continuity Plan for learning continuity

If your institution has Business Continuity Plan provisions for continued learning in the event of an LMS outage, surface them now and confirm the operational steps required to activate them. Given the active vendor-side intrusion picture, a precautionary readiness posture is warranted now, before any further deterioration.

3.4 Engage your cyber insurer proactively

Even where notification is not yet contractually required, an early conversation with your insurer:

• Preserves coverage options.

• Ensures the insurer's preferred forensic and legal panels can be engaged quickly if needed.

• Is consistent with the duty of disclosure most policies require.

A brief call now is significantly easier than contesting a claim later.

3.5 Confirm your regulatory clocks are being tracked

Both the Privacy Act 1988 (Cth) Notifiable Data Breaches scheme (Australia) and the Privacy Act 2020 (New Zealand) treat awareness held by an agent, in this case Instructure, as awareness held by the principal in defined circumstances. The assessment clock may already be running.

The assessment can and should be commenced and documented before tenant-specific confirmation arrives from the vendor. See §3.3 of the original report for the framework detail.

4. Vendor-side developments: where to watch

Material vendor-side developments are being tracked at Instructure's status page: status.instructure.com. We are monitoring it continuously and will incorporate confirmed material, including tenant-specific advisories, forensic findings, or scope revisions, into subsequent dated updates above.

Where the status page and threat-actor public messaging diverge, the status page is the authoritative source.

Advisory & Remediation Report

1. Executive Summary

This is a supply-chain incident, and all Canvas-using institutions should act on a precautionary basis.

The breach has been confirmed at the supplier — Instructure, operator of the Canvas Learning Management System (LMS) — not at any individual customer institution. Tenant-specific impact can only be confirmed by Instructure in writing, on a per-customer basis, and that confirmation may take weeks. Waiting for it before commencing remediation is not a defensible posture.

Canvas is used by approximately 8,000 educational institutions globally. On 30 April 2026, Instructure publicly disclosed a cybersecurity incident affecting Canvas Data 2 and Canvas Beta environments, with downstream disruption to any tooling reliant on Canvas Application Programming Interface (API) keys. By 2 May 2026, Instructure had confirmed that a criminal threat actor perpetrated the attack, that the incident was contained, and that personal information belonging to users at affected institutions had been accessed.

The extortion group ShinyHunters has claimed responsibility and listed Instructure on its Tor-based leak site, asserting exfiltration at large scale (claimed figures of approximately 275 million users, 9,000 institutions, and 3.65 TB of data — all unverified). ShinyHunters has further asserted that Instructure's Salesforce instance was compromised as part of the same campaign. The threat actor has set a ransom deadline of 6 May 2026; assume a public data dump is possible from that date forward, and align community communications and regulator notifications accordingly.

Instructure has confirmed exposure of: names, email addresses, student ID numbers, and user messages. The vendor has stated that, based on current findings, passwords, dates of birth, government identifiers, and financial information were not involved. These findings remain subject to forensic verification.

The message content within the dataset is unstructured — and that matters. Instructure's statement addresses structured data fields, but free-text messages exchanged between students, teachers, and staff routinely contain personal information that an attacker can extract — dates of birth, addresses, medical and welfare disclosures, behavioural records, family circumstances, and assessment context. The absence of a 'date of birth (DOB) field' in the leaked structured records is not the same as the absence of dates of birth in the leaked data overall. Institutions should not adopt the vendor's structured-field statement as a basis for concluding that no sensitive information has been exposed.

This is the second confirmed Instructure incident in eight months. A September 2025 social-engineering attack against Instructure's Salesforce environment was also publicly attributed to ShinyHunters at the time. The recurrence — and the re-implication of the Salesforce platform — indicates remediation gaps from the 2025 event that customers should weigh in vendor-risk decisions, and aligns with a broader pattern of edtech-sector targeting that has previously affected PowerSchool and Infinite Campus.

Key implications for affected institutions:

• The exposed data set (names + institutional email + student ID + message content) is materially sufficient to support highly targeted social engineering, phishing, and account takeover attacks against students, parents, and staff. The presence of message content significantly raises the risk of pretext-based fraud relative to a typical Personally Identifiable Information (PII) only breach.

• All Canvas API integrations, third-party Learning Tools Interoperability (LTI) tools, and Student Information System (SIS) data flows that rely on Canvas-issued credentials should be treated as potentially exposed until rotated and reauthorised, irrespective of vendor-side rotation actions.

• The list of 'affected' institutions circulating publicly is not authoritative. Any victim list released by the threat actor or republished in media should be treated as unverified, potentially incomplete, and potentially inaccurate — it may include institutions that are not Canvas customers, omit institutions that are, or misrepresent the scope of exposure for those listed.

• The regulatory clock has started. Privacy assessment under the Privacy Act 1988 (Cth) Notifiable Data Breaches (NDB) scheme (AU) and the Privacy Act 2020 (NZ) should commence on the assumption that exposure is plausible. Under the NZ Act in particular, knowledge held by Instructure as agent may be attributed to the institution — the assessment window may already be open.

This advisory provides a structured remediation pathway across immediate (0–72 hours), short-term (1–4 weeks), and longer-term (1–6 months) horizons, together with user communications guidance suitable for staff, student, and parent audiences. The most time-sensitive actions are in §4.1.

2. Incident Timeline & Technical Details

2.1 Disclosed timeline

2.2 Attack vector — what is publicly known and what is not

Instructure has not publicly disclosed the technical attack vector for the May 2026 incident as of the time of writing. Independent reporting and ShinyHunters' own statements indicate the following:

• The threat actor claims exploitation of a vulnerability in Instructure's systems, since reportedly patched.

• The disruption signature — specifically affecting Canvas Data 2, Canvas Beta, and API-key-dependent tooling, combined with Instructure's response action of rotating application keys — is consistent with compromise of an application-layer credential, token, or service-account pathway rather than end-user credentials.

• The threat actor's claim that the Salesforce instance was also breached mirrors the September 2025 incident, where social engineering against Salesforce was the documented vector. Whether the May 2026 Salesforce compromise is a fresh intrusion or persistence from the prior event is not yet established.

• The broader ShinyHunters 2025–2026 campaign has been characterised by OAuth token abuse, voice-phishing (vishing) of help-desk staff, and Salesforce data-loader-style exfiltration patterns observed at unrelated victims (e.g., reporting around ADT, Amtrak, McGraw-Hill). Institutions should treat any of these as plausible — not confirmed — vectors pending Instructure's forensic disclosures.

2.3 Threat actor context — ShinyHunters

ShinyHunters is a financially motivated extortion group active since approximately 2020, with a 2025–2026 campaign focused on large data brokers, cloud Software-as-a-Service (SaaS) platforms, and education technology vendors. The group's modus operandi typically involves:

• Initial access via credential theft, social engineering of support and admin staff, or exploitation of misconfigured SaaS integrations.

• Bulk data exfiltration via legitimate API or platform tooling, minimising malware footprint.

• Listing on a Tor-based leak site, with structured extortion deadlines and partial sample releases to validate claims.

• Public pressure via media engagement and selective release of victim data to journalists.

This profile is relevant for institutions because it implies that direct intrusion into customer (school) environments is unlikely to be the immediate concern; the dominant residual risk is fraud, social engineering, and downstream account compromise driven by the leaked dataset.

2.4 Data scope (per vendor as of 2 May 2026)

Confirmed exposed:

• Full names of users (students, teachers, other staff)

• Email addresses (institutional and personal where stored)

• Student ID numbers

• Message content exchanged within Canvas (student-to-student, student-to-teacher, teacher-to-teacher, system-to-user)

Stated by Instructure as not exposed:

• Passwords / authentication credentials

• Dates of birth

• Government-issued identifiers

• Financial / payment information

Caveats: These boundaries reflect Instructure's findings as at 2 May 2026 and are subject to revision. Message content alone may contain free-text references to dates of birth, addresses, medical information, behavioural records, or assessment outcomes — institutions should not equate 'no DOB field exposed' with 'no DOB exposed'.

2.5 Indicators & artefacts

At present, no high-fidelity network Indicators of Compromise (IOCs) — Internet Protocol (IP) addresses, hashes, or domains — tied specifically to the May 2026 Instructure intrusion have been publicly released. Detection and hunting effort should therefore focus on:

• Anomalous Canvas API usage in the institution's tenant in the 14 days prior to 30 April 2026, particularly bulk reads via Canvas Data 2 endpoints.

• OAuth and developer-key activity for any institution-owned Canvas integrations.

• Phishing emails referencing Canvas, Instructure, password resets, 'incident notification', 'verify your account', or claiming to be from institutional IT.

• Lookalike domains registered after 30 April 2026 incorporating tokens such as canvas-, instructure-, lms, login.

3. Impact Assessment for Educational Facilities

3.1 Direct data exposure impact

A note on victim attribution: at the time of writing, the only authoritative source of tenant-level impact is Instructure itself, communicated directly and in writing to the customer institution. Any list of 'affected schools' circulating in public — whether via the threat actor, social media, or media reporting — should be regarded as unverified. Such lists have historically been shown to contain institutions that are not customers of the affected vendor, to omit institutions that are, and to overstate or understate exposure depending on the actor's incentives. Institutions should neither take comfort from being absent from such a list nor accept inclusion as definitive.

The realistic worst-case data exposure profile, assuming exposure has occurred, is:

The combination of institutional email + verified student ID + private message context is materially more dangerous than a typical PII breach because it enables an attacker to construct phishing lures that reference real conversations, real teachers, and real coursework — bypassing the contextual checks that staff and students normally rely on to detect fraud.

3.2 Operational impact

• API integration disruption. Any third-party tool integrated to Canvas via developer key, OAuth client, or API token will have been forced through reauthorisation following Instructure's 2 May rotation. Institutions should expect a tail of broken integrations (gradebook sync, plagiarism detection, proctoring, SIS sync, analytics warehouses) requiring administrative re-consent.

• Canvas Data 2 dependent reporting. Institutions using Canvas Data 2 for analytics, compliance, or finance reporting will have experienced an outage between approximately 1 May and 3 May 2026, with potential data-completeness gaps for that window.

• LTI 1.3 tools. LTI integrations relying on platform-issued client credentials may require re-registration depending on whether tenant-level keys were among those rotated.

3.3 Regulatory and contractual impact

This advisory is written for an Australian and New Zealand audience. Privacy law in both jurisdictions operates principally at the national level, and the remediation pathway in this advisory is anchored to those two frameworks. State-level legislation in Australia is touched on where genuinely applicable, but should not be assumed to apply by default to most institutions in the sector. Cross-border frameworks may apply concurrently for institutions with international students or operations.

Australia — Privacy Act 1988 (Cth) and the Notifiable Data Breaches scheme

The Privacy Act 1988 (Cth) applies to most education-sector institutions in Australia, including:

• All private schools, independent schools, and Catholic schools (as Australian Privacy Principles (APP) entities, given the sector's revenue profile).

• All private universities and private higher education providers.

• All private registered training organisations.

• All Commonwealth Government agencies and ACT Government agencies (which are covered by the Privacy Act).

For these institutions, the Notifiable Data Breaches (NDB) scheme under Part IIIC of the Privacy Act applies. Where there are reasonable grounds to suspect an eligible data breach affecting Australian individuals — that is, unauthorised access to personal information likely to result in serious harm — the institution must:

• Conduct a reasonable and expeditious assessment of the suspected breach within 30 days of forming the suspicion, to determine whether it is an eligible data breach.

• If it is an eligible data breach, notify the Office of the Australian Information Commissioner (OAIC) and the affected individuals as soon as practicable after the determination is made.

• Document the assessment, the decision, and the rationale — including for 'no notification required' outcomes, which require equally robust justification.

The presence of free-text message content in the leaked dataset materially raises the likelihood of 'serious harm', because messages may contain disclosures (medical, welfare, behavioural, family) whose exposure has a clear pathway to psychological, reputational, or safeguarding harm.

New Zealand — Privacy Act 2020

The Privacy Act 2020 applies to all 'agencies' handling personal information about individuals in New Zealand, including New Zealand schools, kura, tertiary providers, and government agencies. There is no public/private distinction equivalent to Australia's APP-entity threshold — coverage is broad.

Key points for the current incident:

• A privacy breach is notifiable where it is reasonable to believe it has caused, or is likely to cause, serious harm to an affected individual.

• Notification to the Office of the Privacy Commissioner (OPC) must be made as soon as practicable after the agency becomes aware of the notifiable breach. The OPC's published expectation is that notification should occur within 72 hours of awareness, absent extenuating circumstances.

• Affected individuals must also be notified as soon as practicable, subject to the limited exceptions in section 116 of the Act.

• Notifications can be made via the OPC's NotifyUs online tool. Institutions should locate and familiarise themselves with this tool before they need it.

• The Act treats knowledge held by an agent or third-party processor of an agency as knowledge held by the agency itself. Practically, this means that once Instructure (acting as an agent in respect of NZ student data) was aware of the breach, that awareness can be attributed to the NZ institution. The clock does not necessarily start when the institution receives a vendor email — it can start earlier.

• Information Privacy Principle 12 (IPP12) restricts the disclosure of personal information to overseas recipients unless specific conditions are met. Given that Instructure is US-based and that Salesforce (US-based) is implicated as a sub-processor, the appropriate disclosure basis under IPP12 should be confirmed as part of vendor review.

The penalty regime under the Act includes fines of up to NZD 10,000 for specific offences (including failure to notify the Commissioner of a notifiable breach), as well as broader civil remedies through the Human Rights Review Tribunal, which can order compensation and other remedies for affected individuals.

State-level privacy law in Australia — limited applicability

Unlike the Privacy Act 1988 (Cth), state and territory privacy legislation in Australia applies only to state public-sector agencies — not to private organisations. For the education sector, this means:

• State government schools are covered by the privacy law of their relevant state (e.g., the Privacy and Personal Information Protection Act 1998 (NSW), the Privacy and Data Protection Act 2014 (Vic), the Information Privacy Act 2009 (Qld), the Personal Information Protection Act 2004 (Tas), and the Information Act (NT)).

• Public universities may be covered by state privacy law in addition to (or in some cases instead of) the Cth Privacy Act, depending on jurisdiction. NSW, Victorian, and Queensland public universities, for example, are covered by their respective state acts.

• Public Technical and Further Education (TAFE) institutes are typically covered by their relevant state framework.

• Independent schools, Catholic schools, private universities, and private RTOs are not covered by state privacy law — their privacy obligations are governed by the Cth Privacy Act.

State privacy frameworks generally include their own breach notification or reporting expectations, often via the relevant state Privacy Commissioner, Information Commissioner, or Ombudsman. Institutions in the public-sector cohort should reference the specific framework applicable to them; institutions outside that cohort should not allow state-law references to confuse a Cth Privacy Act-led response.

Sector-specific obligations

Separate from privacy law, the following may apply:

• Australia: the Tertiary Education Quality and Standards Agency (TEQSA), the Australian Skills Quality Authority (ASQA), and state education departments may impose incident-reporting obligations on registered providers. The Security of Critical Infrastructure Act 2018 (SOCI Act) does not currently designate education as a critical infrastructure sector, but institutions providing services to designated sectors should review any flow-down obligations.

• New Zealand: the Ministry of Education and the New Zealand Qualifications Authority (NZQA) may have notification expectations for registered providers, particularly where student safety or continuity of education is implicated.

Cross-border considerations — international students and offshore operations

Where institutions have international student populations, offshore campuses, or transnational education delivery, equivalent foreign frameworks may apply concurrently. The most likely candidates are:

• General Data Protection Regulation (GDPR) — EU and UK GDPR — applicable where personal data of individuals in the EU or UK is being processed. Notification to the relevant lead supervisory authority is required within 72 hours of awareness of a personal data breach likely to result in a risk to individuals' rights and freedoms.

• Family Educational Rights and Privacy Act (FERPA) — US — applicable to educational institutions that receive US Department of Education funding. Generally not applicable to AU/NZ institutions absent specific US federal funding relationships.

• Children's Online Privacy Protection Act (COPPA) — US, updated rule effective 22 April 2026 — applicable where an institution is directed at, or knowingly collects personal information from, US children under 13. Generally not applicable to AU/NZ institutions absent that specific connection.

In practice, for most AU and NZ institutions, the operative frameworks are the Privacy Act 1988 (Cth) and the Privacy Act 2020 (NZ) respectively, with GDPR/UK GDPR potentially relevant for institutions with EU/UK student cohorts. FERPA and COPPA are unlikely to apply unless the institution has a specific US connection, and should not be defaulted into communications or assessments where that connection does not exist.

Cross-border data flow — a contractual point

Both AU APP 8 (cross-border disclosure of personal information) and NZ IPP12 place obligations on institutions that disclose personal information to overseas recipients. Instructure is US-based; Salesforce, named as a sub-processor in this incident, is US-based. Institutions should, as part of their post-incident vendor review, confirm that the contractual basis for overseas disclosure remains intact and that the recipient remains subject to comparable safeguards. Where APP 8 reasonable steps are relied upon, the recurrence of incidents at the recipient should inform an institution's view of whether those steps remain reasonable.

Vendor contractual position

Institutions should review Canvas master service agreements, data processing agreements, and any sub-processor schedules for:

• Breach notification Service Level Agreements (SLAs) — timing, content, channel.

• Indemnity and liability allocation.

• Audit rights and post-incident reporting commitments.

• Sub-processor disclosure and consent (notably, the Salesforce relationship).

• Cross-border data flow basis under APP 8 (AU) and IPP12 (NZ).

• Renewal and termination rights, given the recurrence pattern from September 2025.

3.4 Safeguarding impact (K-12 specific)

For K-12 institutions, the exposure of message content involving minors warrants specific safeguarding consideration:

• Messages may contain disclosures of welfare concerns, mental health issues, or sensitive pastoral information.

• The threat surface includes child-targeted social engineering using leaked message context.

• Parental notification approach must be carefully designed to avoid amplifying harm or driving panic, while satisfying duty-of-care expectations.

Safeguarding and Data Protection Officer (DPO) / privacy functions should be involved in incident response from the outset — not as a downstream notification step.

4. Remediation Actions

The following actions are organised by horizon. Sequencing assumes that the institution is a Canvas customer and that exposure is plausible but not confirmed. Public victim lists should not drive the decision to act — the only authoritative confirmation will come from Instructure directly, and waiting for it before commencing remediation is not appropriate. All Canvas-using institutions should follow at minimum the immediate-horizon actions on a precautionary basis, and scale subsequent activity as tenant-specific information becomes available.

4.1 Immediate (0–72 hours)

Top priority — rotate credentials and keys held by Canvas to access your source systems

This is the single most important immediate action and warrants explicit, separate treatment. It is distinct from the activities Instructure has performed on its side of the boundary.

Canvas does not operate as a closed system. To synchronise identity, classroom, and SIS data, Canvas typically holds credentials, API keys, OAuth client secrets, or app-registration secrets that grant it access into the institution's source systems — most commonly:

• Microsoft Entra ID (formerly Azure Active Directory, Azure AD) app registrations used for System for Cross-domain Identity Management (SCIM) provisioning, Graph API directory reads, or Single Sign-On (SSO) trust relationships.

• Synergetic API users / integration accounts configured under the Synergetic admin panel for SIS data sync.

• Identity One, TASS, Edumate, or other SIS / Identity Management (IDM) platform integration accounts used in similar capacity.

• Any bespoke service accounts in source systems (HR, finance, library) that Canvas or its integrations consume.

The working assumption must be: if a credential or key was held inside Canvas / Instructure infrastructure at the time of the breach, that credential or key must be treated as compromised. A stolen Canvas-side credential to your Entra tenant can be used to exfiltrate directory data well beyond what Canvas itself was ingesting, or to maintain access for use in later attacks.

Action — do this today, ahead of any other identity activity:

1. Inventory every credential, key, OAuth client secret, app-registration secret, certificate, and API account that Canvas (and any Canvas-side integration) uses to authenticate into your environment.

2. Expire or rotate each one at the source-system end:

   • In Microsoft Entra ID: review Enterprise Applications and App Registrations linked to Canvas / Instructure. Rotate client secrets, revoke and reissue certificates, and review consented Graph API permissions for least-privilege.

   • In Synergetic: review the admin panel for API users and integration accounts associated with the Canvas integration. Expire passwords / keys and reissue.

   • In Identity One / TASS / Edumate / other SIS or IDM: perform the equivalent rotation under that platform's integration-account or API-credential management.

3. Provide the rotated values to Canvas via the supported configuration path so the integration is restored.

4. Be prepared to repeat this exercise. Instructure has stated the underlying vulnerability has been addressed; however, as forensic findings develop and as the breach plays out, additional credential exposure may come to light. Treat one rotation as a starting point, not a final answer. Plan for at least one further rotation in 4–8 weeks, and additional rotations if Instructure issues further disclosures.

5. Where rotation breaks an integration, do not roll back to the old credential. Resolve the integration issue with rotated credentials in place.

Identity and access (continuing)

• Force a password reset for all Canvas-authenticated accounts that do not federate to a primary Identity Provider (IdP), even though Instructure has stated passwords were not exposed. This is a defence-in-depth measure against undisclosed exposure and against credential-stuffing pivots.

• For SSO-federated tenants, confirm that Multi-Factor Authentication (MFA) is enforced for all Canvas access at the IdP layer and that legacy authentication paths (basic auth, app passwords, deprecated OAuth flows) are disabled.

• Audit all Canvas developer keys, API tokens, OAuth clients, and LTI tool registrations in your tenant's admin console. Rotate any institution-issued developer keys. Revoke any tokens not actively in use.

• Identify any service / break-glass accounts with Canvas access and rotate their credentials. Place them in a documented, monitored vault.

Detection and hunt

• Open a named incident ticket and treat all Canvas-related telemetry as in-scope for the next 30 days minimum.

• Inventory the data flows into Canvas. Document, for each integration, exactly which attributes are synced from Entra / Synergetic / Identity One / TASS / Edumate / other source systems into Canvas. This inventory is the basis for understanding what data may be in the leaked dataset for your tenant — and for any subsequent regulatory notification or community communication. Without this inventory, statements about scope cannot be made with confidence.

• Hunt for anomalous Canvas API access in the 14 days preceding 30 April 2026: unusual user agents, bulk enumeration patterns, off-hours access, access from unexpected geographies.

• Hunt for inbound phishing referencing Canvas, Instructure, password resets, 'data breach notification', gift cards, or impersonating institutional IT, with elevated weighting on emails landing after 3 May 2026.

• Hunt for registration of lookalike domains matching canvas-*, instructure-*, lms, login patterns; sinkhole or block as detected.

• Confirm email authentication posture — Domain-based Message Authentication, Reporting and Conformance (DMARC) p=reject, Sender Policy Framework (SPF), DomainKeys Identified Mail (DKIM) — to limit phishing impersonation of the institution's own domains.

Communications

• Issue an early acknowledgement to your community. It is appropriate, at this stage, to publicly acknowledge two things: (a) that the institution is aware of the breach at Instructure, and (b) that the institution uses Canvas. Saying nothing is a worse posture than saying something measured. Do not, however, make definitive statements about specific impact to your community — there is insufficient information to support such statements at this time, and overcommitting either way will require retraction. See Section 5 for tone, structure, and a template.

• Stand up a single source of truth (status page or intranet article) for the institution's response. Reference Instructure's official communications rather than restating them.

• Pre-position draft notifications for staff, students, and parents (see Section 5) so they can be released within hours of any new disclosure from Instructure.

• Brief executive leadership and the data protection / privacy officer with a one-page situational summary and a decision-required item for notification posture.

Vendor management

• Formally request a written breach notification from Instructure if not yet received, including: dates of compromise, specific data fields exposed for your tenant, forensic findings, and confirmation of remediation actions taken on Instructure's side.

• Request evidence of key/credential rotation affecting your tenant.

• Log all vendor communications in your incident record for downstream regulatory and legal use.

User behaviour and immediate awareness

• Issue a single, clearly-branded 'heads-up' message to all staff and (age-appropriately) students within 24 hours, explaining in plain language what has occurred, what data may be involved, and the two or three behaviours that matter most this week (don't click breach-notification emails, don't reset passwords from links, report anything suspicious).

• Brief front-line staff most likely to be socially engineered — IT service desk, finance / accounts payable, executive assistants, HR, admissions, and student services — separately and specifically. These roles are the highest-value targets for follow-on fraud using leaked context, and benefit from a tailored briefing rather than a generic email.

• Brief the service desk specifically on caller verification. Vishing (voice phishing) using leaked names, student IDs, and message context is a realistic post-breach scenario. Ensure the desk has an out-of-band verification step for any caller requesting password resets, MFA resets, or account changes — and that this step is non-bypassable, including for callers claiming to be senior staff.

• Confirm that password reset and MFA reset workflows require something stronger than knowledge of a name, email, or student ID. Where they don't, change them today.

4.2 Short-term (1–4 weeks)

Privacy and regulatory

• Complete a privacy impact assessment of the breach against the framework applicable to your institution: the Cth Privacy Act 1988 / NDB scheme (most AU institutions), the NZ Privacy Act 2020 (NZ institutions), and any state-level scheme that genuinely applies (state public-sector entities only). Document the assessment, the decision, and the rationale — even if the decision is 'no notification required'.

• If notification is triggered, prepare and issue regulator and individual notifications within statutory timeframes:

  • Australia (Cth NDB scheme): assessment must be completed within 30 days of forming a suspicion of an eligible data breach; once an eligible data breach is determined, notification to the OAIC and affected individuals must be made as soon as practicable.

  • New Zealand (Privacy Act 2020): notification to the OPC and affected individuals must be made as soon as practicable after becoming aware of a notifiable privacy breach. The OPC's published expectation is within 72 hours, absent extenuating circumstances. Use the NotifyUs tool.

  • GDPR / UK GDPR (where applicable to international student cohorts): notification to the relevant supervisory authority within 72 hours of awareness.

• Treat the date the institution could reasonably have known as the start of the assessment clock, not the date of the institution's own internal escalation. Under the NZ Privacy Act, knowledge held by the agent (Instructure) may be attributed to the principal agency.

• Engage legal counsel on contractual recourse against Instructure, particularly given the recurrence pattern from September 2025, and on the cross-border disclosure basis under APP 8 (AU) and IPP12 (NZ).

Detection uplift

• Deploy or tune phishing-resistant detections specifically modelling the leaked dataset: emails referencing real teacher names, real student IDs, or message thread context.

• Increase monitoring sensitivity on accounts identified as high-value (executives, finance, HR, IT admins, safeguarding leads) for the 90-day post-incident window.

• For institutions running Canvas alongside Microsoft 365 / Google Workspace, enable enriched identity protection signals (Entra ID Identity Protection risk events, Workspace alert centre) and ensure Security Operations Centre (SOC) visibility into both estates.

• Where a Managed Detection and Response (MDR) / SOC capability exists, confirm that Canvas-relevant log sources (where available — IdP, email gateway, Endpoint Detection and Response (EDR) on staff endpoints) are flowing to the Security Information and Event Management (SIEM) platform with retention sufficient for forensic look-back.

Third-party integrations

• Conduct a full inventory of LTI and API integrations with Canvas. For each: validate the vendor is reputable, the access scope is minimum-necessary, and the integration is still required.

• Re-issue and rotate any tokens or keys for those integrations that have not been touched as part of Instructure's forced rotation.

• Document the integration inventory as part of an updated third-party / sub-processor register.

User-side hardening and behaviour change

• Run a targeted phishing simulation scoped to Canvas-themed lures, against staff and (where appropriate) senior students. Use lure content that mirrors the realistic post-breach threat: fake breach notifications, credential-reset prompts, 'verify your account' pages, and impersonations of teaching or IT staff.

• Refresh incident reporting channels and the visibility of the report-phishing button in mail clients. A reporting rate is a leading indicator — track it for the 90-day post-incident window.

• Deliver a short, mandatory micro-training module (5–10 minutes) to all staff covering: recognising breach-themed phishing, the leaked-context impersonation risk, safe link-handling habits, and the institution's reporting path. Track completion as a compliance metric.

• For K-12 contexts, deliver age-appropriate awareness sessions to students through pastoral or homeroom channels rather than email-only. Focus on: not sharing Canvas screenshots externally, not engaging with suspicious DMs that reference real coursework, and how to report concerns to a teacher or safeguarding lead.

• Brief parents/carers in K-12 environments through the institution's normal parent-communication channel, with practical guidance: how to verify an email genuinely came from the school, what the school will and will not ask via email, and how to report suspected scams targeting their child.

• Update the service-desk and HR onboarding/offboarding scripts so that the leaked-data threat model is reflected in caller verification and account provisioning steps for at least the next 12 months.

4.3 Long-term (1–6 months)

Vendor risk management

• Update the institution's vendor risk register to reflect Instructure's recurrence pattern. Re-tier Canvas as an elevated-risk vendor for at least the next 12 months.

• Require Instructure to provide, in writing: a post-incident report, evidence of independent assessment of remediation, attestation regarding Salesforce integration security controls, and a forward-looking commitment around breach-notification SLA.

• Use the renewal cycle to negotiate stronger contractual breach-notification timelines (target: 72 hours from vendor awareness, mirroring GDPR-style obligations).

Architectural review

• Conduct an edtech platform threat-modelling exercise covering Canvas, SIS, identity, and downstream analytics. Particular focus on data-flow minimisation: what actually needs to be sent to Canvas vs. what is sent because of legacy SIS integrations.

• Review whether student ID numbers continue to make sense as an identifier exposed to Canvas, given they have now been confirmed leaked at scale and are typically also used as weak identity factors elsewhere in the institution.

• Where feasible, move Canvas authentication entirely behind the institution's IdP with conditional access policies (device compliance, network location, risk-based) and phishing-resistant MFA (FIDO2 / passkeys) for staff and administrative roles.

Capability investment

• Assess SOC / MDR coverage for the SaaS estate, recognising that traditional network-based monitoring does not see SaaS-internal events. Coverage should include IdP, email security, EDR, and where licensed, Cloud Access Security Broker (CASB) / SaaS Security Posture Management (SSPM) telemetry.

• Develop or refine an edtech-specific incident response playbook covering this exact scenario (vendor-side LMS breach with downstream PII and message exposure). Test it via tabletop exercise within the next quarter.

Sector engagement

• Engage with sector-specific information-sharing groups:

  • Australia: AusCERT (the Australian Computer Emergency Response Team) and the Australian Signals Directorate (ASD) / Australian Cyber Security Centre (ACSC) at the national level; the Council of Australasian University Directors of Information Technology (CAUDIT) for higher education; state education departments for K-12.

  • New Zealand: CERT NZ (the Computer Emergency Response Team for New Zealand) at the national level; the National Cyber Security Centre (NCSC-NZ); Network for Learning (N4L) for the schools sector; the Ministry of Education for state and state-integrated schools.

  • Share sanitised observations, particularly any phishing patterns observed against your own users.

4.4 Security awareness, user behaviours, and cyber hygiene

Technical controls alone will not contain the downstream risk from this incident. The most material residual threat is socially-engineered fraud and account compromise, enabled by the combination of leaked names, institutional emails, student IDs, and message context. Closing that gap is principally a behavioural and hygiene problem, not a tooling problem.

The actions below are intended as a sustained programme over 6–12 months, not a one-off response. Institutions should resist the temptation to issue a single all-staff email and treat awareness as discharged.

Programme design principles

• Treat the post-breach window as a multi-month elevated-risk period, not a 30-day spike. ShinyHunters releases and downstream fraud tend to play out over quarters, not weeks.

• Segment the audience: executive and finance staff, IT and service desk, teaching staff, professional / administrative staff, students, parents/carers. Each cohort needs different content and a different channel.

• Measure behaviour, not attendance. Phishing report rate, time-to-report, simulated-click rate, and service-desk verification-step adherence are leading indicators. Module completion is a lagging compliance metric and should not be the only measure.

• Avoid fear-based messaging. Awareness content that frames users as the weakest link erodes the reporting culture. Frame users as the institution's primary detection sensor — because they are.

Targeted role-based briefings

• Executives, governing body, and finance. Brief on Chief Executive Officer (CEO) fraud and invoice-redirection risk specifically. The leaked dataset enables convincing impersonation of named teaching and administrative staff. Reinforce the dual-authorisation requirement for payment changes, and ensure executives know that a request from a 'colleague' via email — even one referencing real internal context — does not meet that bar.

• IT service desk. Drill on caller-verification protocols. Specifically test: a caller who knows a student ID, full name, and a recent Canvas message should not pass identity verification on those data points alone. Every member of the desk should be able to articulate the out-of-band verification step without consulting documentation.

• HR, admissions, student services. Brief on identity-verification protocols for staff and student-facing transactions, particularly anything that triggers an account, payment, or grade change. Update standard operating procedures to reflect that previously 'trusted' identifiers (student ID + DOB + name) are no longer sufficient where the data has been leaked.

• Teaching staff. Brief on impersonation risk — both impersonation of them by an external actor, and impersonation of students or other teachers contacting them. Provide a clear escalation path for anything that feels off, even if the message references real coursework.

• Students (age-appropriate). Cover: reporting suspicious messages, not sharing Canvas screenshots in public forums (which increase the leakable context), recognising that the school will not ask for passwords by message, and how to report sextortion or harassment using leaked context.

• Parents and carers. Cover: verifying communications that claim to be from the school, recognising scam contact targeting their child via leaked information, and how to report.

Cyber hygiene fundamentals to reinforce

The leak does not change which cyber hygiene practices matter — but it materially raises the cost of skipping them. Reinforce, audit, and where necessary enforce:

• Phishing-resistant MFA (FIDO2 / passkeys, or at minimum number-matching push) for all staff and administrative roles. Short Message Service (SMS) and Time-based One-Time Password (TOTP) only MFA should be deprecated for privileged access.

• Unique passwords for institutional accounts versus personal accounts, supported by an institution-sanctioned password manager. Even though Canvas passwords were not exposed, leaked email addresses will be combined with credentials from prior unrelated breaches in credential-stuffing attacks against institutional logins.

• Browser and OS patch currency on staff devices. A successful phish that lands on an unpatched browser is a materially worse outcome.

• Email handling habits. Hover before click, navigate via bookmarks rather than email links for sensitive systems, never enter credentials on a page reached from an email link, and preview URLs before authenticating.

• Reporting habits. A single, well-known reporting path (button in mail client, or memorised mailbox), with rapid acknowledgement to the reporter. Acknowledgement speed correlates strongly with future reporting rates.

• Account hygiene. Periodic review of connected apps, OAuth grants, and personal-account links to institutional services. Deprovision dormant accounts on a defined cadence.

• Device hygiene. Lock screens when unattended, no shared logins, no shoulder-surfable credential entry in classrooms or staff rooms. Trivial in concept, frequently observed in breach root-cause analyses.

• Data minimisation in messages. Reinforce — particularly with teaching and pastoral staff — that Canvas messages are not an appropriate channel for sensitive personal information, medical disclosures, behavioural records, or safeguarding content. The current incident is a concrete demonstration of why. Establish or re-publicise the approved channels for these categories.

• Public-facing content review. Reduce the institution's external 'context surface' where feasible — staff directories with full email addresses, student directories, and similar resources are inputs to social engineering and should be reviewed for necessity.

Cyber hygiene controls to verify (technical floor)

The following are well-established baselines (aligned with the ACSC Essential Eight for Australian institutions) that take on heightened importance in the post-breach window. Where any of these is not in place at Maturity Level 1 (ML1) or above, prioritise:

• Application control on staff endpoints

• Patch applications and operating systems within risk-aligned timeframes

• Configure Microsoft Office macro settings to disable untrusted macros

• User application hardening (browser, PDF reader, Office)

• Restrict administrative privileges; review and reduce standing admin

• Multi-factor authentication, with phishing-resistant methods for privileged and remote access

• Regular, tested backups of institutional data with offline / immutable copies

Sustained-awareness activities

• A rolling 12-month awareness calendar with at least one activity per month — phishing simulation, micro-training, themed comms, or tabletop exercise.

• Quarterly phishing simulations with progressively more sophisticated lures, including breach-themed and Canvas-themed variants. Track report rate as the primary metric.

• Annual scenario-based training for IT, service desk, and senior leadership — including a tabletop exercise specifically modelling a vendor-side SaaS breach involving student data.

• New-starter induction updated to include the leaked-data threat context, the verification protocols, and the reporting path. Awareness should not be back-loaded into annual refreshers.

• 'Just-in-time' prompts integrated where possible — for example, banners on inbound external email, warnings on first-time-sender messages, and prompts before sharing files externally.

Measurement

Track and report to leadership on a quarterly basis:

• Phishing simulation click rate (target: declining trend)

• Phishing simulation report rate (target: rising trend; > simulation click rate)

• Time-to-report for real and simulated phishing (target: median < 10 minutes)

• Service-desk verification-step adherence (sampled audit)

• Awareness module completion (compliance baseline)

• Number of suspected phishing reports per 1,000 staff per month (volume indicator)

A rising report rate combined with a falling click rate is the signature of a working programme. A flat report rate with a falling click rate often indicates training fatigue rather than improvement.

5. User Communications Guidance

The objective of user communications is to enable defensive behaviour without inducing panic or undermining trust in the institution's own systems. The following guidance assumes three primary audiences: staff, adult students, and parents/carers of K-12 students.

5.1 Principles

• Lead with what is known, not what is claimed. Distinguish between Instructure's confirmed exposure (names, emails, student IDs, messages) and ShinyHunters' unverified claims (volume, scale, Salesforce). Avoid restating ransom demands or threat-actor branding.

• Be specific about action. Vague 'stay vigilant' advisories are routinely ignored. Provide two or three concrete behaviours.

• Acknowledge the message-content dimension. Users need to understand that the leak is not a typical 'your email and name were leaked' event — the message context materially raises the impersonation risk. Communicate this without sensationalising.

• Provide a reporting path. Every communication should include a single, prominent way to report a suspected phishing or impersonation attempt.

• Coordinate with safeguarding and pastoral teams before issuing communications referencing students under 18.

5.2 Suggested message structure (template, adapt institution-locally)

Subject line approach: Direct and informational. Avoid 'URGENT' / 'ALERT' framing that mimics phishing.

Opening (1–2 sentences): State that Instructure, the operator of Canvas, has confirmed a data breach affecting users at numerous institutions globally. State whether your institution has been confirmed affected, is awaiting confirmation, or has been advised it is not affected.

What was involved: List the data fields confirmed by Instructure: names, email addresses, student ID numbers, and messages exchanged within Canvas. State explicitly that Instructure has reported that passwords, dates of birth, government identifiers, and financial information were not involved based on current findings.

What you (the user) should do:

• Be especially cautious about emails or messages claiming to be from Canvas, Instructure, or institutional IT — particularly any asking you to reset a password, click a link, or 'verify' your account.

• Do not click links in unsolicited 'data breach notification' emails. Navigate to Canvas directly via your bookmark or the institution's portal.

• If something looks off — even if it references something real, like a recent assignment or message — report it via [institutional reporting path].

• [For staff] Be alert to fraudulent requests that reference real student or teacher names, real coursework, or real internal conversations. The leaked data may make impersonation attempts more convincing than usual.

• [For parents/carers of K-12] If your child reports an unusual message or contact, please report it to [safeguarding contact].

What we are doing: Briefly describe institutional response: monitoring, reviewing Canvas integrations, working with Instructure, applying additional safeguards. Avoid technical detail in user-facing communications.

Where to get more information: Provide a single link to the institution's dedicated information page, and Instructure's official update page. Avoid linking to media coverage.

Closing: Provide the reporting path again. Sign from a named, senior accountable person (Chief Information Officer (CIO), Chief Information Security Officer (CISO), Director of IT) — not 'IT Department'.

5.4 Early acknowledgement message — recommended template

In the immediate window — before tenant-specific impact is confirmed by Instructure — the recommended posture is a warm, factual, community-facing acknowledgement that the institution is aware of the breach and uses Canvas, without making claims about specific impact that the institution is not yet in a position to make. The message should reassure without overcommitting, and clearly position the institution as actively engaged with the supplier and partners on the community's behalf.

Template (adapt institution-locally):

Dear [community / parents / staff / students],

You may have seen reporting of a recent cybersecurity incident affecting Instructure, the supplier of the Canvas Learning Management System. We use Canvas at \[Institution\], and we want to let you know that we are aware of the incident and are actively engaged in understanding what it means for our community.

At this stage, the breach has been confirmed at Instructure. Whether, and to what extent, our \[Institution\] data is involved is not yet clear, and is something we are working to establish. We are in regular communication with Instructure, with our security partners, and with relevant industry associations to understand the situation and, where possible, mitigate any risks to our community.

Internally, our IT and security team has begun a precautionary review of the data flows between our systems and Canvas, the credentials and integrations involved, and the protections in place around the platform. Where appropriate, we are taking action ahead of further information from Instructure rather than waiting for it.

We will provide a further update as we have more information. In the meantime, we would ask everyone in our community to be alert for emails or messages claiming to be from Canvas, Instructure, or \[Institution\] IT, particularly any that ask you to reset a password, click a link, or 'verify' your account. If anything looks unusual, please report it to \[reporting channel\] and navigate to Canvas through your usual bookmark rather than via links in emails.

Thank you for your patience as we work through this. The privacy and safety of our community is our priority.

\[Named accountable senior — CIO / CISO / Head of IT / Principal\]

Why this works:

• Acknowledges the situation without amplifying threat-actor framing or unverified figures.

• States the supply-chain context clearly — the breach is at the supplier, not the institution.

• Avoids overcommitment in either direction (does not say 'your data is safe', does not say 'your data is exposed').

• Demonstrates active engagement — the institution is already in motion, not waiting passively.

• Provides one or two concrete behaviours for the recipient, without a list that will not be read.

• Provides a reporting path as a primary call to action.

• Names an accountable signatory, which materially increases trust and reduces the 'this might be a phishing email' reflex.

What to also do internally before issuing this message:

• Inventory what attributes are synced from Entra / Synergetic / Identity One / TASS / Edumate / other source systems into Canvas (per Section 4.1). This is what will eventually make a more specific community statement possible. Without it, follow-up communications will be unable to characterise scope.

• Confirm that the named signatory is genuinely available to respond to inbound questions for the 48 hours following release. A 'no reply' or unanswered inbox after a community message will erode trust quickly.

• Provide front-line staff (reception, service desk, pastoral leads) with a short Q&A so they can hold consistent lines if asked.

5.5 What to avoid

• Do not restate threat-actor figures (275M, 9,000 schools, 3.65 TB) in user-facing comms unless contextualised. These figures are unverified.

• Do not name the threat actor in user communications. It serves no protective purpose and risks amplifying the actor's brand.

• Do not include credential-reset links inline. Direct users to navigate via known paths only.

• Do not issue communications outside of business hours unless materially necessary; off-hours messaging mimics phishing.

• Do not make absolute statements ('your data was definitely / definitely was not affected') until Instructure has provided tenant-specific written confirmation.

5.6 Internal stakeholder briefings

Distinct briefings should be prepared for:

• Executive leadership / governing body — risk posture, regulatory status, residual decisions.

• Heads of school / faculty leads — pastoral and academic implications, expected questions from staff and parents.

• Communications / media team — approved Q&A and holding statements in case of external enquiry.

• IT / SOC team — full technical advisory (this document).

• Safeguarding / DPO — child-protection implications and notification obligations.

——

Congratulations on making it to the end of our report! 😉

You're invited to join the SecOps team for a live briefing tomorrow morning - Friday 8 May 2026 @ 10am.

🗓️ Analyst Update for Aussie Schools - Instructure (Canvas LMS) Data Breach

It'll be a detailed, relaxed and open discussion. 👍