Why do education organisations stay exposed to repeated phishing attacks?

Why This Matters for Security Teams

Education environments remain attractive to phishers because the attack surface is unusually broad: student accounts, staff mailboxes, research partners, alumni services, cloud apps, and third-party learning platforms all sit behind the same trust expectations. That makes identity and access governance harder than in smaller, steadier organisations. Guidance in NIST SP 800-53 Rev 5 Security and Privacy Controls is relevant here because phishing resilience depends on layered controls, not user awareness alone.

The common mistake is treating phishing as a training problem when it is also an access control and session protection problem. If a captured password can still be used without step-up checks, device signals, or anomaly detection, the organisation has already lost the more important part of the fight. In education, the volume of legitimate email churn and seasonal onboarding often masks suspicious activity until an account is used to send more phishing internally. In practice, many security teams encounter repeated phishing only after a mailbox, token, or shared service account has already been abused to reach others.

How It Works in Practice

Repeated phishing succeeds when attackers exploit the gaps between identity proofing, authentication, and post-login monitoring. A school or university may have MFA in place, but if recovery workflows are weak, if legacy protocols remain enabled, or if session tokens are long-lived, a single successful lure can still create durable access. Public-facing guidance from CISA cyber threat advisories consistently shows that credential theft is only one step; the follow-on abuse often depends on persistence, lateral movement, and internal delivery.

Operationally, effective defence depends on combining identity, email, and endpoint controls:

• Enforce phishing-resistant MFA where possible, especially for staff, administrators, finance, and research accounts.
• Reduce the value of stolen credentials by limiting session duration, detecting impossible travel, and revoking risky tokens quickly.
• Review external sharing, delegated mailbox access, and app consent settings so attackers cannot turn one account into a distribution point.
• Monitor for known attacker tradecraft such as inbox rule abuse, OAuth abuse, and suspicious authentication patterns using the MITRE ATT&CK Enterprise Matrix.

This is also where automation helps, but only when it is tightly governed. Education teams can use alert triage, conditional access, and SOAR playbooks to block repeated lures faster, yet those tools need tuning for academic calendars, mobile-heavy access patterns, and legitimate collaboration outside the institution. Where AI is used to generate or tailor lures, the threat landscape overlaps with the MITRE ATLAS adversarial AI threat matrix and emerging reporting such as Anthropic — first AI-orchestrated cyber espionage campaign report, which underscores how attackers are scaling social engineering with better targeting and faster iteration. These controls tend to break down when shared accounts, legacy authentication, and unmanaged third-party integrations are common because attribution and containment become too slow.

Common Variations and Edge Cases

Tighter phishing controls often increase friction for students, faculty, and visiting collaborators, requiring organisations to balance resilience against usability and support burden. That tradeoff is especially sharp in education, where short-term project staff, guest lecturers, and research partners may not fit a single access pattern.

Best practice is evolving for high-risk exceptions. For example, some environments allow broader access for low-risk learning tools while requiring stronger controls for payroll, grading, finance, and research administration. That is reasonable, but only if the exception list is reviewed and expiring. There is no universal standard for how often every account in education should be reverified, though the practical answer is to review more frequently where privilege, payment data, or external sharing is involved.

Another edge case is student-led collaboration. A platform may be secure in isolation, yet repeated phishing still spreads because users forward messages, reuse passwords, or approve prompts without context. NHI governance matters here too: service accounts, shared inboxes, and automation identities should not be treated as informal exceptions. The strongest programmes align account lifecycle, mail security, and logging so a compromised identity can be contained before it becomes a campus-wide relay point.

Related resources from NHI Mgmt Group

• Why do passkeys still leave organisations exposed to phishing attacks?
• When does a phishing-resistant login method still leave organisations exposed?
• Why do AI-driven phishing attacks still succeed when organisations use modern authentication?
• Why do legacy MFA methods still leave organisations exposed to phishing?