Every institution's cybersecurity leader faces the same tension: the institution needs its people to adopt powerful tools for teaching and research, and it needs to protect the institutional identity that makes those tools possible. For many institutions, one of the most visible examples of that tension is third-party OAuth and OpenID Connect governance. Nearly every institution with a Google or Microsoft identity provider is now fielding a growing volume of requests from third-party applications that recognize the institutional identity and ask users to grant access to institutional data. Faculty adopt AI writing tools. Students sign up for productivity apps. Researchers connect collaboration platforms. Each of these interactions triggers an OAuth or OIDC consent flow that connects the application to the institution's identity infrastructure.
Many institutions are still working out how to support this volume of requests effectively. Some have no controls in place, leaving the security team with no visibility into what is connecting to institutional systems. Others have implemented controls so restrictive that faculty and students route around them using personal accounts, which produces the same result: no visibility. Both extremes leave the security team overwhelmed and the institution exposed.
A note on terminology: throughout this guide, "CISO" refers to whoever owns the IT risk and cybersecurity function, whether that is a titled Chief Information Security Officer, a director of IT security, a CIO wearing multiple hats, or a shared-services arrangement. The guidance applies regardless of where the function lives on the org chart.
The institutional identity, the .edu account managed through Microsoft Entra ID or Google Workspace, is now the load-bearing infrastructure of the digital campus. It is what connects a researcher to licensed journals, a student to the LMS, and a faculty member to collaboration tools. When it works well, it enables seamless, passwordless access across a broad ecosystem of services. Protecting that infrastructure while preserving that seamlessness is the core challenge this guide addresses.
The challenge is visible on screens across campus every day. A faculty member finds a new AI writing tool and clicks its "Sign in with Google" button. Their institution's login page appears, and they authenticate normally. Then a consent screen appears: "[App Name] wants to access your Google Account," followed by a list of requested permissions that might include "Read, compose, and send email" or "See, edit, and delete all your Google Drive files." The faculty member clicks "Allow," the same way they would accept a terms-of-service agreement, and moves on to the tool they need. The same flow occurs with "Sign in with Microsoft" and Entra ID. It happens thousands of times per semester across a typical university, and unless someone on the security or identity team has been specifically tasked with reviewing these requests, the institution may have no visibility into the connection.
In that moment, the user is doing two things at once: authenticating their identity and granting the application a set of permissions to access institutional data on their behalf. Those permissions might be narrow (verify my name and email) or broad (read my entire inbox, access all my files). Most users do not distinguish between these, and many do not realize they are accepting permissions at all. Once granted, the application receives an OAuth token that operates independently of the user's login session, persists for months or years, and bypasses multi-factor authentication entirely. The user does not need to log in again. The application simply accesses the data directly.
Three converging forces have accelerated the volume of these connections: the ubiquity of OAuth 2.0 and OpenID Connect as authentication protocols, the decentralized culture of academic IT where departments and individual faculty operate with significant autonomy, and the rapid adoption of generative AI tools that request institutional account access for summarization, writing assistance, and data analysis.
The result is that universities must now govern an infrastructure defined not by firewalls and network segments, but by every consent decision made by every person who authenticates with institutional credentials. This guide treats that as an infrastructure challenge, not a policing challenge. We maintain the roads so people can drive safely, not so we can control where they go.
This guide presents a governance framework built around a single principle: make the safe choice the easy choice, and provide a clear path forward for everything else.
The framework establishes four pathways for managing third-party connections to institutional identity infrastructure, ranging from instant access for enterprise-licensed tools to a supported review process for tools that need deeper evaluation. It reduces the CISO's operational burden by automating decisions at both ends of the spectrum (pre-approved tools that need no review and structurally incompatible tools that will always be denied), freeing capacity for the reviews that actually require human judgment.
The technical controls are straightforward. Both Microsoft Entra ID and Google Workspace provide built-in consent management that can enforce the framework at no additional licensing cost. The governance processes align with existing higher education standards, including EDUCAUSE guidance, CISA baselines, and community assessment tools such as the Higher Education Community Vendor Assessment Toolkit (HECVAT) (EDUCAUSE, 2024; Isora GRC, 2025; REN-ISAC, n.d.-b; CISA, n.d.).
The case for acting now is grounded in operational reality. In August 2025, attackers stole OAuth tokens from Salesloft's Drift integration and used them to access more than 700 Salesforce environments, because the tokens operated independently of user login sessions and were never subject to MFA (Valence Security, 2025). Cloudflare, Zscaler, and Tenable were among the organizations affected. The attack did not require exotic techniques. It exploited the gap between a vendor's OAuth access and the victim organizations' ability to govern it.
Because OAuth tokens operate outside the user's authentication session (REN-ISAC, n.d.-a), user training and strong authentication are not sufficient on their own. The control must be architectural.
Some apps are structurally incompatible with institutional data protection obligations. Consumer rewards apps that scan institutional email are a common example. For these, the framework provides a clear, explainable rationale for blocking, along with communication templates that explain why and offer alternatives. Users retain full freedom to use these apps with personal email accounts or by registering directly with a username and password. The governance applies to the OAuth connection to institutional infrastructure, not to the software itself.
This guide provides the risk analysis, regulatory context, technical implementation guidance, and communication templates needed to implement a defensible governance framework that works within higher education's culture of shared governance and academic freedom.
Understanding how OAuth actually works is essential for making defensible governance decisions. This section provides the technical foundation that informs every recommendation in this guide.
When a user authorizes a third-party app through OAuth, the identity provider (the university's Google or Microsoft tenant) issues an access token to that app. Unlike a password, which the user controls, the token operates independently of the user's active session. A student might use a "PDF Converter" once, grant it Drive access to upload a single file, and never think about it again. But that application retains a valid token to access the student's Drive for months or years. If that PDF Converter is later acquired by a malicious actor or suffers a breach, the attacker inherits persistent access to the university's infrastructure.
This is the point that surprises many users and IT leaders: OAuth tokens bypass multi-factor authentication entirely (REN-ISAC, n.d.-a). Once the token is issued, the third-party app accesses the API directly. The user is not logging in; the app is logging in on their behalf. This means the university's most significant authentication investment, MFA, provides zero protection against this specific vector. A compromised third-party app with a valid OAuth token can read email, access files, or send messages without ever triggering an MFA challenge.
This is why "training users to be careful" is not a sufficient control. Users can be perfectly diligent about their own login behavior and still have their data exposed through a compromised third-party token they granted months ago and forgot about. The control must be architectural.
The risk depends on the specific permissions ("scopes") requested. A benign app might request only openid (verify identity) and profile (name, email). A consumer app with a data-harvesting business model might request Mail.Read (read all email), Files.Read.All (read all files), or Calendar.Events (read the user's schedule). Most end users do not read scope descriptions carefully, and even those who do may not understand the implications. A student granting Mail.Read to a receipt-scanning app has effectively given that app access to every email in their institutional inbox, including professor communications, financial aid correspondence, and health-related messages.
The risk extends beyond the third-party developer's intent to their own security posture. In December 2024, attackers compromised 36 Chrome browser extensions serving 2.6 million users by phishing extension developers through fake OAuth consent screens (Cyberhaven, 2024). Once the developers authorized the malicious app, the attackers pushed poisoned updates to every user of those extensions. Because the extensions already held OAuth tokens with broad permissions, MFA never triggered. The 2022 breach of Heroku and Travis CI OAuth tokens demonstrated the same pattern at the platform level: attackers stole tokens from widely used, legitimate developer platforms and used them to pivot into dozens of victim organizations (GitHub, 2022). In August 2025, stolen OAuth tokens from Salesloft's Drift integration gave attackers access to more than 700 Salesforce environments, affecting organizations including Cloudflare, Zscaler, and Tenable (Valence Security, 2025).
For a university, the implications are direct. A similar breach in a citation manager, browser extension, or research collaboration tool could lead to exfiltration of pre-publication research data, patent-pending innovations, or sensitive human-subject data. The compromised tool does not need to be malicious. It only needs to be breached.
This framework will fail if it creates bottlenecks that delay research or teaching. Faculty autonomy over pedagogical tools is a legitimate institutional value, not an obstacle to be managed. The governance framework must be designed to honor that autonomy while protecting the infrastructure that makes it possible.
When security processes create too much friction, faculty route around them. They use personal email, personal credit cards, and free-tier accounts to acquire the tools they need. This does not reduce risk. It makes risk invisible to the institution. The "Department of No" pattern produces the worst possible outcome: the security team loses visibility AND the institution loses protection. The OAuth governance framework is designed to prevent this by keeping the governed path faster and easier than the workaround.
The framework preserves faculty autonomy in three specific ways:
The American Association of University Professors (AAUP) has cautioned that technology offices can restrict resources or monitor communications in ways that chill free inquiry (AAUP, 2014). This is a legitimate concern. The governance framework addresses it directly: it governs the OAuth connection between third-party apps and the institutional identity, not which tools faculty can use. A professor can use any tool they choose with a personal account or by registering directly with the tool outside of the university's identity infrastructure. The governance applies only to the institutional identity infrastructure, which the institution has both the right and the obligation to protect.
Conversations about OAuth governance in higher education often focus on FERPA requirements. But from a risk perspective, the more significant exposure is likely negligence. When an institution provides email accounts, has the technical capability to restrict OAuth access using platform controls included in existing licenses at no additional cost, knows that consumer apps scan email contents (this is widely documented), and takes no protective action, plaintiffs can argue the institution breached its duty of reasonable care. Institutions should discuss these questions with legal counsel. The goal here is to identify where the risk lives, not to provide legal interpretation.
The risk is not limited to consumer apps behaving as designed. A legitimate tool that researchers or students have connected to the institutional identity can itself become a source of compromise. Developer account takeovers, malicious updates, and supply chain attacks can give an attacker access to every OAuth token that tool holds. Depending on what those users had in their accounts, the exposed data could include pre-publication research and intellectual property, student or human-subjects data, financial aid correspondence containing Federal Tax Information, or health information. The institution didn't choose the tool, didn't vet it, and may not even know it was connected.
Recent settlements illustrate the magnitude of negligence exposure for data protection failures at peer institutions. None of these cases involved OAuth specifically, but they suggest that courts may be receptive to claims against institutions that fail to implement reasonable controls over data access:
Active litigation against Princeton University, University of Pennsylvania, and University of Phoenix (via the Oracle third-party breach) suggests ongoing judicial receptivity to institutional negligence claims. The December 2024 PowerSchool breach, which exposed records for 62 million students and 9.5 million educators through compromised vendor credentials, has generated its own wave of legal action and regulatory scrutiny (Proskauer Rose LLP, 2025).
The connection to OAuth governance is straightforward. If these institutions face multimillion-dollar liability for general data protection failures, an institution that takes no action to govern third-party OAuth access, using free, built-in platform controls, may face an even more difficult argument that it exercised reasonable care.
Higher education institutions are not hypothetical targets for OAuth-based attacks. Since at least September 2025, a suspected Russia-aligned threat actor tracked as UNK_AcademicFlare has conducted OAuth device-code phishing campaigns targeting universities, government agencies, and think tanks (Swain, 2025). The technique tricks users into entering a device authorization code on a legitimate Microsoft login page, granting the attacker a persistent OAuth token that operates without triggering MFA.
The reputational calculus is equally concrete. No parent, prospective student, or accreditation body will distinguish between "the university was breached" and "a student authorized an app that was breached using university credentials." The institution's name is on the headline either way.
There is a legally plausible argument that student-initiated OAuth access to consumer apps does not constitute an "institutional disclosure" under FERPA (FERPA, 1974). The statute prohibits educational agencies from maintaining policies or practices that permit disclosure of personally identifiable information from education records without consent. When a student voluntarily authorizes a consumer app to scan their inbox, the institution did not disclose anything; the student did.
The Privacy Technical Assistance Center (PTAC) has published extensive guidance on cloud computing and third-party service providers, but all existing materials address school-selected vendors operating under institutional control (PTAC, 2015). No Department of Education guidance directly addresses consumer app OAuth access initiated by students.
This distinction may matter for legal counsel, but it should not drive the governance decision. Even a successful FERPA defense may not prevent negligence claims, may not prevent reputational damage, may not prevent state attorney general investigations under breach notification statutes, and may not prevent the loss of public trust. The institution should implement architectural controls because they protect the infrastructure, not because FERPA compels it.
That said, FERPA does apply directly in one important scenario: faculty-directed use of unvetted tools. When a professor requires students to create accounts on an unvetted platform using their .edu identities, that is arguably an institutional disclosure. The School Official exception under 34 CFR § 99.31(a)(1)(i) requires that the vendor perform a service the school would otherwise use employees for, that the institution maintain direct control over education records, and that the vendor not re-disclose data for non-educational purposes (FERPA, 1974). Most consumer apps and many free EdTech tools may fail all three requirements, particularly the "direct control" test. Without a Data Protection Agreement (DPA) that restricts data use to the educational purpose, the institution lacks the contractual mechanism to assert control. This scenario is addressed through the Consultative Review path described later in this guide.
A related compliance risk hides inside seemingly benign "directory info only" scopes. When an OAuth app syncs the university's Global Address List, it processes names, email addresses, and departmental affiliations for all users, including students who have exercised their FERPA opt-out rights (sometimes called a "FERPA hold" or "suppression list"). Automated OAuth grants do not check the suppression list. This means any app consuming directory data will inevitably process records for students who have explicitly opted out, potentially creating a compliance gap that many institutions are not monitoring for.
Additionally, the context of app usage can transform directory information into a protected record. If a student uses their .edu identity to authenticate into an app called "Academic Probation Support," the mere association of their identity with that app reveals academic standing, which is highly protected under FERPA regardless of whether the app receives any data beyond the student's name and email.
FERPA is only one layer of the compliance stack. Several additional frameworks apply and compound the governance requirements.
A one-size-fits-all policy does not work in higher education. The governance framework must align vetting effort with risk exposure while keeping the review process fast enough that users don't look for workarounds. This framework establishes four pathways, each defined by the level of service provided and the data access involved (EDUCAUSE, 2024). Each pathway carries a suggested risk color (green, yellow, orange, red) to help visual learners in documentation and presentations.
Before entering the review process, apply a threshold test that protects the security team's capacity:
Triage rule: if the app is a consumer product (not an enterprise or educational tool), AND it requests Mail.Read, Mail.ReadWrite, Files.Read.All, Files.ReadWrite.All, or equivalent broad data scopes, AND the institution has no contractual relationship with the vendor, we immediately classify it as Incompatible. We do not spend cycles on a vendor review for a tool that cannot pass.
This triage rule exists to serve the campus, not just the security team. Every hour spent reviewing an app that should be denied is an hour that delays approving an app that could be allowed for legitimate use. By clearing the queue of obvious non-starters, the security team can deliver faster turnaround on reviews that are more likely to be approved.
The governance pathways require a formal method for evaluating third-party applications. The depth of assessment should scale with the pathway: lighter review for Expedited Review, comprehensive review for Consultative Review. Institutions typically draw from several approaches, and most use a combination:
The right approach depends on the institution's size, staffing, existing procurement workflows, and the tools already in use. What matters is that the method is documented, repeatable, and scales with data sensitivity.
These are enterprise-licensed tools with existing institutional contracts and DPAs. Examples might include the university LMS (Canvas, Blackboard, D2L), Microsoft 365 core apps, Zoom, and Adobe Creative Cloud. They are already vetted at the enterprise level and should be pre-consented or trusted in the identity platform.
What users experience: no friction. These tools work the same way they always have.
What this enables: faculty and staff can adopt and use core institutional tools without any interaction with the security review process. This is the path that covers the vast majority of daily tool usage and is the primary mechanism for keeping governance invisible where it should be.
Established vendors with moderate data access requirements (calendar, basic profile) and no retention of PII. Examples might include scheduling tools like Calendly, project management tools like Trello or Asana, and citation managers like Zotero. User consent may be allowed if the app comes from a verified publisher, and a lightweight vendor risk assessment provides sufficient due diligence. The 1EdTech TrustEd Apps program provides a useful fast-track mechanism for this path: apps holding the 1EdTech "Data Privacy Certified" seal have been vetted against a standardized privacy rubric and can be auto-approved or expedited through the review process.
What users experience: a brief review period with a published, predictable response-time commitment. Users can request access through the app portal and receive a clear timeline.
What this enables: faculty and departments can adopt productivity and collaboration tools with minimal delay and a predictable process.
Apps that access sensitive PII (grades, health information, financial data) or request read/write access to mail or file storage, AND have a legitimate educational or institutional purpose. Examples might include online proctoring tools, AI-powered educational technology requesting document access, research collaboration platforms handling sensitive data, and financial aid processing integrations. These require a comprehensive vendor risk assessment, legal review, a signed DPA, accessibility review, and admin consent.
What users experience: a thorough review with a published response-time commitment. The security team works directly with the requestor to understand the use case and expedite where possible. For faculty needing to experiment while the review is in progress, a research sandbox can be provisioned as an interim measure.
What this enables: tools with genuine institutional value that handle sensitive data can be adopted through a supported process. The institution gets the contractual protections (DPAs, breach notification clauses, data return requirements) that protect both the university and its users.
Apps whose business model or technical requirements are structurally incompatible with the institution's data protection obligations. This includes apps that meet the triage criteria above, plus apps with known malicious intent, predatory data practices, or fundamental incompatibility with institutional obligations. Examples might include consumer rewards apps that scan institutional email, unverified "free" VPN apps, PDF scrapers with data-harvesting terms, apps that claim ownership of user-generated content, and apps previously flagged in breach disclosures.
What users experience: a clear message explaining why the app is incompatible with connecting to the institutional identity infrastructure, what specific data is at stake, and how to access the app without the institutional identity (using a personal email account or registering directly with a username and password). Users also see a link to the app request portal in case they believe the classification is incorrect.
What this enables: users retain full autonomy to use these apps with personal email or direct registration. The institutional identity is protected, and the security team's review capacity is preserved for Expedited Review and Consultative Review requests.
The Incompatible classification is not a judgment on the app or the user. It is a statement about structural compatibility. Consumer rewards apps, for example, typically operate a business model built on scanning inbox data for marketing intelligence. Their privacy policies may disclose that the app scans for any data believed to be a receipt and retrieves billing addresses, names, payment methods, products purchased, and other information contained in the email. Independent evaluation tools such as Common Sense Privacy can help institutions and users research the data practices of specific apps before connecting them to institutional accounts.
FTC enforcement actions confirm that the risk is not hypothetical. In 2019, the FTC's enforcement action against Unrollme/Slice Technologies (Docket No. 172 3139) found that Slice's automated email crawler captured and copied entire message bodies, storing personal information including names, billing and shipping addresses, and credit card information (FTC, 2019). These actions provide directly relevant precedent for institutions evaluating structural compatibility.
This business model is built to monetize data. The institution's obligation is to protect data. These are incompatible specifications. A student's institutional inbox may contain FERPA-protected professor communications, financial aid correspondence potentially including FTI, disability services and health center messages, and academic advising records. The incompatibility is mechanical, not moral. Users who want to participate in consumer rewards programs can use personal email addresses or register directly with those apps outside of the institutional identity. The university identity is infrastructure for education, research, and campus life.
AI tools are already the primary stress test for any third-party governance framework. New tools surface weekly. Faculty and students connect them to institutional accounts before anyone in IT knows they exist. If this framework cannot handle that volume and velocity, it is useless. The OAuth governance framework is designed specifically for it.
The governance challenge is concrete, not hypothetical. Students and faculty are connecting institutional accounts to unvetted AI tools for writing assistance, summarization, and data analysis. If these tools use input data for model training, sensitive intellectual property or student data could be ingested into a public model. This is an irreversible data exposure with no breach notification remedy.
AI tools should be assessed through the same governance framework as every other third-party application:
The key message to faculty: the institution is investing in making AI tools available through governed channels. Research sandboxes provide an immediate option for experimentation. The review process for AI tools follows the same timelines and commitments as any other Consultative Review.
Microsoft Entra ID provides granular consent controls, but default configurations do not include the governance controls most institutions need. Active configuration is required. CISA's ScubaGear assessment tool provides specific policy recommendations for Entra ID (CISA, n.d.):
For higher education, the recommended approach balances CISA's strict baseline with the need for academic flexibility (AppGovScore, n.d.):
Any scope granting access to organizational data should require explicit administrator approval, including Mail.Read, Mail.ReadWrite, and Mail.Send (all mailbox access); Files.Read.All and Files.ReadWrite.All (organizational file access); Chat.Read and Chat.ReadWrite (Teams conversations); User.Read.All and Directory.Read.All (tenant directory data); and any application-level (non-delegated) permissions.
Microsoft Teams administration offers additional controls through the Teams Admin Center, including org-wide settings for third-party apps, custom policies targeting specific user groups, and the newer App Centric Management approach that enables per-app user and group assignments (Microsoft, n.d.). For institutions in GCC, GCC High, or DoD environments, all third-party apps are blocked by default.
Google's model differs architecturally from Microsoft's and requires separate configuration guidance (Google, n.d.).
The "Basic Info" baseline. The recommended default for faculty and staff is to allow users to access third-party apps that only request basic information. This is the pragmatic middle ground: it permits "Sign in with Google" for authentication (reducing password fatigue) while preventing apps from accessing Drive, Gmail, or Calendar data. This setting is the technical foundation of Standard Service for Google Workspace institutions.
Restricted scopes. Administrators should identify high-risk API scopes and set them to "Restricted" status. Once restricted, no app can access those scopes unless an administrator explicitly marks it as "Trusted." The critical scopes to restrict include gmail.readonly and all Gmail scopes (this is the control that addresses consumer email-scanning apps), drive and drive.readonly (prevents unvetted file access), cloud-platform (prevents broad GCP access), and calendar.events (prevents schedule harvesting). This approach blocks data-harvesting apps while allowing authentication-only use cases.
Under-18 protections. For accounts designated as under 18 (relevant for dual-enrollment students and K-12 partnerships), the default must be set to "Don't allow users to access any third-party apps" unless individually allowlisted. This is a strict safety requirement to comply with the Children's Online Privacy Protection Act (COPPA) and the additional FERPA protections for minors.
Admin audit logging. Even without a dedicated Cloud Access Security Broker (CASB), Google Workspace administrators can access token audit logs in the Admin Console showing every consent event: who authorized which app, when, and with what scopes. This provides baseline visibility into Shadow IT and should be reviewed regularly.
Leading research universities have converged on similar frameworks, confirming that this approach aligns with community practice.
Transitioning to the OAuth governance framework should be sequenced to avoid disrupting campus operations while addressing the highest risks first (EDUCAUSE, 2024).
The hardest part of this governance framework is not the technical configuration. It is the communication and cultural alignment. The following templates address the most common friction points. Bracketed items are placeholders for the institution to fill in.
This is what users should see when they attempt to authorize a blocked application. Configure it in the Entra ID admin consent workflow or the Google Workspace block screen. Note that the "what you can do" section leads.
What you can do:
- If this is a personal app (like a rewards program), you can use it with a personal email account or register directly at the app's website with a username and password.
- If you need this app for coursework or research, submit a request through [link to app request portal] and our team will review it within [X] business days.
- Browse approved alternatives at [link to approved app catalog].
Why this app is blocked: [App Name] requests access to your entire university email inbox, including academic records, financial aid correspondence, and professor communications. This app's data practices are not compatible with the university's obligation to protect institutional data.
Questions? Contact the IT Help Desk at [contact info].
Use this when student government leadership, campus media, or student advocacy groups raise concerns about blocked apps.
We understand the frustration when a familiar app is blocked, and we want to explain the reasoning clearly.
Your .edu identity is institutional infrastructure, like your student ID or your access to the library. It connects you to your courses, your professors, your financial aid, and every university service you use. For example, apps like shopping rewards programs work by scanning your entire email inbox for potential receipts. But your university inbox contains far more than receipts: communications with professors, financial aid notifications that may include sensitive personal information, health center messages, and academic records. When you grant an app access to read your email, you grant access to all of it, not just the parts the app says it wants.
This app's business model is built on monetizing inbox data. The university's obligation is to protect that data. These are incompatible requirements, and that is why the app cannot operate within the university's identity infrastructure. You are free to use any such app with a personal email account or by registering directly at the app's website. We are not telling you what apps you can or cannot use. We are maintaining the integrity of the institutional infrastructure you depend on.
If you believe a blocked app has a legitimate academic or institutional use case, we have a review process at [link to request portal]. We review requests within [X] business days and are committed to approving tools that serve the university's mission while protecting your data.
Use this when faculty raise concerns about blocked tools or perceive the governance framework as overreach.
We recognize that access to the right tools is essential for your teaching and research, and we are committed to getting you what you need as quickly as possible.
The consent controls are not a blanket lockdown. Apps that only need to verify your identity (single sign-on) continue to work without any IT involvement. The controls apply when an app requests access to your email, files, or other university data.
Here is why this matters for your work specifically: if you are handling research data subject to IRB protocols, grant-funded work with data management plan requirements, or student records in any form, an unvetted third-party app connected to your institutional account could put your compliance status at risk. For DoD-funded researchers, uncontrolled OAuth access may conflict with NIST 800-171 and CMMC requirements (Ross et al., 2020; U.S. Department of Defense, n.d.).
We have built the review process to be as fast as possible: Standard Service tools (Canvas, Zoom, Adobe, Microsoft 365) require no review and work now; Expedited Review tools (established tools requesting limited access) go through a light-touch review; and Consultative Review tools (tools requiring access to sensitive data) require a full review. Each path has a published response-time commitment.
If you need to experiment with unvetted tools for research purposes, we can provision an isolated research sandbox environment that is separated from enterprise university data. Contact [research computing contact] to discuss options. Submit app requests at [link to request portal]. If a review is taking too long or you need expedited access, contact [CISO or IT security lead name] directly at [email].
Use this when presenting the framework to faculty senate, IT governance committees, or institutional leadership.
The OAuth governance framework is a proposal for governing how third-party applications connect to institutional identity infrastructure. We are presenting it to this body for input before finalizing implementation.
The problem we are solving. Under default configurations for most identity providers, any member of the campus community can connect a third-party application to their institutional identity with a single click, granting it access to email, files, and calendar data. Without active configuration changes, the university has no visibility into these connections and no contractual relationship with most of the apps involved. This creates legal exposure (peer institutions have settled breach-related claims for millions of dollars), compliance risk (GLBA, FERPA, NIST 800-171), and operational burden (the security team cannot triage what it cannot see).
What the framework does. It establishes four pathways for third-party connections to institutional identity infrastructure, ranging from instant access for enterprise-licensed tools to a clear explanation and alternatives for apps whose data practices are incompatible with institutional obligations. The framework is implemented using built-in controls in Microsoft Entra ID and Google Workspace at no additional licensing cost.
What the framework does not do. It does not restrict what tools faculty, staff, or students can use with personal accounts or direct registration. It does not create blanket blocks on categories of software. It does not give IT veto authority over pedagogical decisions. It does not monitor the content of your research or teaching; it only governs the data connection between an app and the university identity. It provides a supported path for requesting access to tools that need review.
Where we need your input. We are seeking feedback on the review process timelines, the criteria for path classification, and the communication approach. We want this framework to reflect the institution's values, not just its risk posture. Supporting documentation, including the technical controls, regulatory analysis, and peer institution models, is available at [link].
Higher education institutions have a dual obligation: to enable academic freedom and innovation, and to protect the institutional data and identity infrastructure that make both possible. These obligations are not in conflict. They reinforce each other. A researcher cannot do their best work if their pre-publication data is exposed through an unvetted app. A student cannot trust the institution with sensitive information if that information is accessible to consumer data brokers. Faculty cannot maintain academic freedom if the tools they depend on are compromised through supply chain vulnerabilities.
The OAuth governance framework resolves the tension between enablement and protection by providing clear, fast, and transparent pathways for tool adoption while maintaining architectural controls that protect the data everyone depends on. It is designed for the specific culture of higher education: decentralized governance, faculty autonomy, diverse user populations, and resource-constrained IT teams.
The regulatory environment does not demand perfection. It demands that the institution demonstrate reasonable care using readily available technical controls and governance processes. The controls described in this guide are available within existing platform licenses at no additional cost. The governance frameworks (EDUCAUSE guidance, CISA baselines, and community assessment tools) are well-documented and community-supported (EDUCAUSE, 2024; CISA, n.d.).
The path forward requires three concurrent efforts:
The negligence settlements at peer institutions demonstrate the cost of inaction (ClassAction.org, 2025a; HIPAA Journal, 2025; ClassAction.org, 2025b; Roman, n.d.). The technical controls are available today. But the real value of this framework is not what it prevents. It is what it enables: a CISO who can stop chasing shadows and focus on enabling the mission, a faculty that can adopt tools with confidence instead of workarounds, and an institution that governs its digital infrastructure with the same care it brings to its physical campus. The framework works because it is built for higher education, not adapted from a corporate playbook.
AAUP (American Association of University Professors). (2014). Academic Freedom and Electronic Communications.
AppGovScore. (n.d.). Entra ID Application Consent: What Identity Admins Need to Know, Part Two.
CISA (Cybersecurity and Infrastructure Security Agency). (n.d.). Microsoft Entra ID Secure Configuration Baseline.
ClassAction.org. (2025a). $5M University of Minnesota Settlement Ends Class Action Lawsuit Over 2023 Data Breach.
ClassAction.org. (2025b). Mercer University Data Breach Settlement Aims to Resolve Lawsuit Over February 2023 Cyberattack.
Cyberhaven. (2024). Cyberhaven's Preliminary Analysis of the Recent Malicious Chrome Extension.
EDUCAUSE. (2024). Third-Party Integrations: Governance and Process Guide.
Family Educational Rights and Privacy Act (FERPA). (1974). 20 U.S.C. § 1232g.
FortifyData. (n.d.). GLBA Compliance for Higher Education: Meeting the Safeguards Rule.
FTC (Federal Trade Commission). (2019). In the Matter of Slice Technologies, Inc., also d/b/a Unroll.Me.
FTC (Federal Trade Commission). (2023). Standards for Safeguarding Customer Information (Safeguards Rule).
GitHub. (2022). Security Alert: Attack Campaign Involving Stolen OAuth User Tokens Issued to Two Third-Party Integrators.
Google. (n.d.). Control Which Third-Party and Internal Apps Access Google Workspace Data.
Harvard University. (n.d.). Working with Vendors and External Services.
HIPAA Journal. (2025). Saint Louis University Agrees to $2 Million Settlement to Resolve Data Breach Lawsuit.
Indiana University. (n.d.). Third Party Services: Legal, Privacy, and Instructional Concerns.
Isora GRC. (2025). What Is the HECVAT? The Complete Guide for Higher Ed in 2025.
Microsoft. (n.d.). Grant and Manage Consent to Teams App Permissions.
NCSL (National Conference of State Legislatures). (n.d.). Security Breach Notification Laws.
Proskauer Rose LLP. (2025). The PowerSchool Breach: A Privacy Lesson on Third-Party Risk Exposure.
PTAC (Privacy Technical Assistance Center). (2015). Protecting Student Privacy While Using Online Educational Services: Requirements and Best Practices.
REN-ISAC. (n.d.-a). AiTM Advisory.
REN-ISAC. (n.d.-b). HECVAT: Higher Education Community Vendor Assessment Toolkit.
Roman, J. (n.d.). University Breach Lawsuit Settled.
Ross, R., Pillitteri, V., Dempsey, K., Riddle, M., & Guissanie, G. (2020). Protecting Controlled Unclassified Information in Nonfederal Systems and Organizations. NIST SP 800-171 Rev. 2. doi:10.6028/NIST.SP.800-171r2.
Stanford University. (n.d.). Third Party Security Requirements.
Swain, G. (2025). Hackers Exploit Microsoft OAuth Device Codes to Hijack Enterprise Accounts. CSO Online.
U.S. Department of Defense. (n.d.). Cybersecurity Maturity Model Certification (CMMC) Program.
U.S. Department of Education, Office of Federal Student Aid. (2025). Guidance on the Use of Federal Tax Information (FTI), FAFSA Data, and Non-FAFSA Data.
Valence Security. (2025). Salesforce OAuth Token Breach: What Every Security Team Must Know.
See how CampusCISO helps higher education security leaders turn an honest assessment into a prioritized, board-ready roadmap.
Explore the three lenses
