On 30 October 2026, Saga University in Japan announced that personal data on about 80,000 students, staff, former students, former staff and related people may have leaked after a ransomware attack. The leaked fields may include names, dates of birth, addresses, phone numbers, email addresses and passwords. The attack hit a network storage device used by the administrative office. The university spotted it at 08:42 on 24 September, and office terminals were back in use at 11:03 on 27 September.
A month earlier, EDUCAUSE released its 2027 Top 10 list of higher education IT issues (reported by Campus Technology on 1 October 2026). Number three is "Balancing cybersecurity boundaries with autonomy and trust".
Put those two documents side by side and a gap shows. The EDUCAUSE text is about culture, communication and trust. The Saga notice ends by warning people about fake emails, SMS messages and phone calls pretending to come from the university. The people who answer those calls, and the people the fake callers pretend to be, usually sit on the same team: the service desk. This article turns issue 3 into changes a university service desk in the GCC can make before the next term opens, using two 2026 incidents and one government advisory as evidence.
What EDUCAUSE wrote about issue 3
The summary on the EDUCAUSE 2027 Top 10 page reads: "Security teams can support an institutional culture that values both clear and transparent security boundaries and individual responsibility and discretion." The body opens with a line that sets the tone: "It's always surprising when cybersecurity isn't the number one issue on the EDUCAUSE Top 10." It then argues for "more agile, collaborative, and decentralized approaches" and names the institution's people as its greatest vulnerability.
Mark McCormack, interim vice president of research, insights and analytics at EDUCAUSE, was blunter in an interview with EdTech Magazine: "We know that the individual user is one of the biggest areas of vulnerability for an institution." Institutions, he said, have to "empower, train and equip the individual person to be that discerning, confident decision-maker in the moment when they don't have their CISO standing over their shoulder."
That moment rarely happens near the CISO. It happens when a student gets an SMS about a "suspended account" at midnight, or when an agent takes a call from someone who sounds exactly like a stressed professor locked out an hour before an exam.
Two 2026 incidents, two different doors
At Saga, the attackers reached a file store. The University of Nottingham lost data from its student records system by another route. The university says it found unauthorised activity in its Campus Solutions platform on 9 June 2026, and that the attacker "exploited a vulnerability in Oracle WebLogic", which allowed remote code execution. The categories it lists as possibly accessed include contact details, student and staff ID numbers, fee payment records and visa information.
Neither breach started at a service desk. Both ended up there. Nottingham told students to update passwords on any account that shared credentials with university systems, pointed them to its Student Enquiry Centre, and set up a dedicated support line. Saga asked its community not to open links or attachments in unexpected messages. Each of those instructions produces tickets, calls and walk-ins. Each also hands a criminal a believable opening line: "Hello, this is IT, calling about the data incident."
The helpdesk is a named target
The joint advisory on the Scattered Spider group from CISA, the FBI and partner agencies, last revised on 29 July 2025, describes attackers who "posed as company IT and/or helpdesk staff using phone calls or SMS messages to obtain credentials from employees". The 2025 update adds the reverse move: attackers posing as employees "to convince IT and/or helpdesk staff to provide sensitive information, reset the employee's password, and transfer the employee's MFA to a device they control". The same advisory lists lookalike domains built as targetsname-helpdesk[.]com and targetsname-servicedesk[.]com.
Universities have a built-in weakness here. Student ID numbers are printed on cards, sent in timetables and, as Nottingham's list shows, stored in the very records that leak. If knowing a student number is enough to get a password reset, the leak becomes the key.
Seven changes for a GCC campus service desk
None of these needs a new budget line. Most are a written process plus a few ticket fields.
1. Write down how agents verify a caller before any reset
Choose the methods your desk accepts and rank them. A callback to the phone number already on the student or HR record beats anything the caller tells you. Photo ID at the service counter beats both. For staff with admin rights, require a second approver. Then record the verification method in every reset ticket, with the agent's name. When an attacker does get through, that line in the ticket history is the first thing the investigation will look for.
2. Never move MFA on a single phone call
Moving an MFA method to a new device is exactly the request the CISA advisory describes. Make it a separate ticket type, slower than a password reset: call back on the old number, notify the old device and the personal email on record, and add a waiting period for privileged accounts. The same advisory recommends phishing-resistant MFA, and the desk is where that rollout succeeds or stalls.
3. Prepare breach-week replies in Arabic and English now
When a notice like Saga's goes out, the same handful of questions arrives again and again. Was my data included? Do I need to change my password? Is this email from you real? Who do I call? What about my fee records? Write those answers in advance as canned responses in both languages, link them to one public status page, and open a ticket category for incident enquiries so you can count them. An agent who types the same answer from scratch all day starts making mistakes, and some of those mistakes will be about security.
4. Tell people what the desk will never ask
Saga warned its community about fake messages after the incident. Do it before. Put one short statement on the portal, in the email signature and in the student welcome pack: the service desk will never ask for your password or a verification code by phone, SMS, WhatsApp or email. Publish the one real helpdesk address and phone number next to it. This is the "clear and transparent security boundaries" half of issue 3 in practice, and it gives students something concrete to check when a message feels off.
5. Plan the forced password reset before you need it
Saga's list of exposed fields includes passwords. If that happened to you in the first week of term, could you reset every account without the desk going under? Self-service reset with an enrolled second factor should carry most of the load. Stagger it by college or faculty, keep it away from registration deadlines, and save agents for the exceptions: students abroad without their old number, new staff who never enrolled MFA, shared lab accounts.
6. Close accounts for people who have left
Look again at Saga's figure. It covers former students and former staff as well as current ones. Accounts and files belonging to people who left years ago are still a liability. Graduation and contract end dates should open leaver tickets automatically, with a fixed checklist: disable sign-in, keep or delete mailbox content according to your retention policy, remove group memberships and shared-drive access. Old departmental file shares need a named owner and a review date, because a file store used by an office is where Saga's incident began.
7. Make reporting a phish quicker than deleting it
The autonomy half of issue 3 means trusting people to make their own calls. That trust only works if reporting is easy and nobody is made to feel foolish for asking. A "report suspicious message" button or address should create a ticket, and every report should get a reply from a person within your SLA, even a two-line one. People who get thanked report again. People who hear nothing stop.
Where friction and security meet
Issue 10 on the same list, "Reducing friction for more seamless technology experiences", can look like it pulls the other way. McCormack's example in the EdTech interview was a student logging in to several systems separately, with the fix being "a single access point". That is also a security gain: one strong sign-in with MFA is easier to protect, and easier to explain, than five weak ones. We covered that trade-off in five logins versus one SSO. The phishing side, including why SMS and app codes do not stop adversary-in-the-middle kits, is in our notes on Microsoft's 2026 Digital Defense Report. For the AI items on the same EDUCAUSE list, see our university AI governance checklist.
A one-hour exercise for next week
Book a room with two agents, one person from information security and one from student affairs. Read the Saga notice aloud and pretend it is about your university. Then walk through three calls. A student wants to know whether their data leaked. A caller who says he is a dean needs his MFA moved to a new phone today. A parent has received an SMS with a link to a "breach compensation" form. Write down every point where an agent had to improvise. That list is your backlog for the term break, and whatever tool runs your desk should be able to hold the answers: the verification record, the canned replies, the incident category.
Frequently asked questions
What is issue 3 on the EDUCAUSE 2027 Top 10?
"Balancing cybersecurity boundaries with autonomy and trust." EDUCAUSE describes it as a culture that values both clear security boundaries and individual responsibility, supported by more collaborative and decentralized approaches.
Why does the service desk matter for university cybersecurity?
It can reset passwords and move MFA, which makes it a target. The CISA advisory on Scattered Spider describes attackers posing as employees to get helpdesk staff to reset passwords and transfer MFA to devices the attackers control.
Is a student ID number enough to verify a caller?
No. Student and staff ID numbers are among the categories the University of Nottingham listed as possibly accessed in its 2026 incident. Use a callback to the number on record, photo ID at the counter, or a second approver for privileged accounts.
What data did the Saga University breach involve?
According to the university's notice of 30 October 2026, names, dates of birth, gender, addresses, phone numbers, email addresses and passwords of about 80,000 students, staff, former students, former staff and related people may have leaked. Patient data was still under investigation.
How should we handle the ticket surge after a breach notice?
Open an incident-enquiry ticket category, prepare canned answers in Arabic and English for the most common questions, link them to one status page, and push bulk password resets to self-service so agents only handle the exceptions.
Sources: Saga University notice, 30 October 2026; EDUCAUSE 2027 Top 10; Campus Technology, 1 October 2026; EdTech Magazine, 8 October 2026; University of Nottingham incident page, updated 20 September 2026; University of Nottingham student news, 10 June 2026; CISA advisory AA23-320A, revised 29 July 2025.
