Who is accountable when a trusted account is used to phish inside a university?

Why This Matters for Security Teams

A trusted account used to phish inside a university is not just a mailbox abuse problem. It is an identity governance failure, an alerting failure, and often a classification failure. Once a legitimate account is weaponised, the sender inherits trust that bypasses user suspicion, mail controls, and sometimes even internal escalation paths. That makes accountability more complex than “who clicked what” and more focused on who owned the account, who approved its access, and who was responsible for monitoring it. The NIST Cybersecurity Framework 2.0 frames this as a lifecycle and governance issue, not a single technical control. NHIMG research on NHI governance shows why visibility and revocation discipline matter when identities are widely distributed and poorly reviewed. In practice, many security teams encounter misuse of a trusted account only after the phishing has already spread through a department, not through intentional review or control testing.

How It Works in Practice

Accountability usually sits across three layers. First is the identity team, which owns authentication, mailbox controls, logging, and conditional access. Second is the business or department owner, who should classify the account’s risk and define whether it handles sensitive communications. Third is the security function, which sets detection, escalation, and incident handling standards. When a university mailbox is used to phish, the question is not only who caused the misuse, but who had the responsibility to reduce the opportunity for abuse. Operationally, teams should treat high-trust mailboxes like high-impact assets. That means:

• explicit ownership and a named approver for every privileged or institution-wide account
• mailbox review and access recertification on a fixed cadence
• alerting on unusual forwarding rules, impossible travel, anomalous sending volume, and new OAuth consent grants
• fast revocation paths for compromised accounts and delegated access
• classification-driven controls for high-risk offices, including athletics, finance, admissions, and HR

This is where NHIMG’s guidance on identity governance is useful, especially the Ultimate Guide to Non-Human Identities, because the same failure pattern appears when a trusted identity retains access longer than its business purpose. For a real-world abuse pattern, the JetBrains GitHub plugin token exposure illustrates how a legitimate credential can become the attack path once trust is inherited rather than continuously revalidated. These controls tend to break down in decentralised university environments where departments manage their own mail workflows and central security lacks consistent visibility into delegated access and forwarding behaviour.

Common Variations and Edge Cases

Tighter accountability often increases administrative overhead, requiring universities to balance faster local operations against stronger central oversight. That tradeoff is real, especially where departments need autonomy for communications and event management. Current guidance suggests that not every trusted account needs the same control set, but there is no universal standard for this yet. A student-facing inbox, an athletics communications mailbox, and a cabinet-level administrative account should not be treated the same way. The more visible and externally trusted the account, the more responsibility shifts toward formal ownership, logging, and rapid response. Edge cases also matter: a shared mailbox may not have a single human user, but it still needs a named business owner; a delegated sending workflow may be legitimate, but it still needs monitoring; and a compromised account used for phishing may implicate both the person who misused it and the team that failed to constrain it. The practical test is simple: if the account can convincingly impersonate the university, then it should be governed as a high-impact identity, not as a convenience inbox. That is the point where accountability becomes shared, documented, and enforceable rather than assumed.

Related resources from NHI Mgmt Group

• Who is accountable when a compromised official account is used for fraud or surveillance?
• Who is accountable when token-based account takeover succeeds?
• Who is accountable when a malicious message arrives through a vendor account?
• How should security teams govern API keys used for generative AI access?