Securing the Digital Campus: Why Legacy Systems Need MFA and SSO

Schools and universities depend on a wide mix of learning platforms, student systems, finance applications, HR tools, and departmental web applications. Many now use modern identity providers for email and cloud services, but important campus systems can still sit outside the central multi-factor authentication (MFA) and single sign-on (SSO) perimeter.

That coverage gap matters. Attackers do not need every system to be weak; they need one exposed login, reused password, or application that campus MFA never reached.

A campus-wide incident shows why identity coverage matters

In May 2026, attackers disrupted Instructure's Canvas platform and compromised data associated with roughly 275 million users across more than 8,800 institutions. Universities postponed exams and project deadlines while access was unavailable. Inside Higher Ed reported that Instructure paid a ransom after the incident.

The lesson is not that a legacy campus application caused the Canvas incident. It did not. The lesson is that education operations now depend on many connected systems, and identity security is only as complete as the applications it covers.

Learning management systems attract attention, but student information systems (SIS), financial aid tools, HR and payroll platforms, enterprise resource planning (ERP) systems, and custom administrative portals can hold equally sensitive data and powerful workflows.

Why campus applications fall outside MFA and SSO

Many long-running campus applications were designed before SAML or OpenID Connect (OIDC) became standard. Others support modern federation only through an upgrade, a system-specific connector, or a specialized configuration project that must be repeated across environments.

The result is a familiar set of problems:

• Separate credentials and security blind spots. Faculty, staff, students, and administrators may use campus SSO for Microsoft 365 or cloud applications, then fall back to a separate password for an administrative system that has no MFA.
• Custom integration work. Extending an identity provider to an older application can require SDK work, custom connectors, application-specific testing, and ongoing maintenance.
• Users outside the campus IdP. Applicants, alumni, contractors, parents, partners, and other external users may need application access without receiving full campus identity accounts.
• Limited IT capacity. The staffing constraint is especially visible in K-12. Education Week reported that 65% of K-12 technology leaders named insufficient staffing and a lack of dedicated budget as their top cybersecurity barriers.

MFA coverage is also a higher education compliance issue

For postsecondary institutions participating in Title IV programs, the Gramm-Leach-Bliley Act (GLBA) Safeguards Rule is directly relevant. Federal Student Aid states that participating institutions and third-party servicers must protect student financial aid information.

The Safeguards Rule requires covered organizations to implement MFA for anyone accessing customer information, unless the Qualified Individual approves an equivalent secure access control in writing. The practical question is not whether the campus IdP supports MFA. It is whether every in-scope application is actually protected by it.

The MFA compliance requirements hub compares GLBA/FSA with other frameworks and explains where requirements differ.

How an access proxy extends MFA and SSO

Datawiza Access Proxy sits in the web application request path and connects existing applications to modern identity controls without requiring a custom authentication connector for each app.

Use the campus identity provider for employees and students

For users who already have campus identities, Datawiza integrates with an existing identity provider such as Microsoft Entra ID, Okta, Ping Identity, Cisco Duo, Google Identity, Shibboleth, or another SAML/OIDC provider. The identity provider performs authentication and MFA before approved traffic reaches the application.

This gives users a familiar campus login while allowing the institution to apply its existing MFA methods, conditional access, and account lifecycle controls to applications that could not join the federation on their own.

Use built-in MFA for users outside the campus IdP

Not every application population belongs in the enterprise directory. With Datawiza built-in MFA, users keep the application's existing username, password, and user store. The application verifies those credentials first; Datawiza then triggers the MFA challenge and grants access only after it succeeds.

This mode can protect applicant, alumni, contractor, partner, or other external-user portals without creating a separate identity provider account or migrating the application's user population.

Pass a trusted identity to the application

After authentication succeeds, Datawiza forwards the verified identity in a form the application can consume, such as a trusted HTTP header or signed JWT. The application origin should accept traffic only through the proxy, and Datawiza strips or overwrites incoming identity headers so a client cannot invent an identity and bypass authentication.

For Oracle PeopleSoft, see the dedicated PeopleSoft SSO and MFA solution. The same access-layer pattern can also protect SIS, HR, finance, research administration, library, and custom departmental web applications.

What changes - and what stays unchanged

An access-layer rollout changes where authentication policy is enforced, not the application's business logic:

• The existing web application and its user workflows stay in place.
• Campus teams can reuse the identity provider and MFA methods they already operate.
• External users can keep existing application credentials when an IdP migration is not appropriate.
• Authentication, MFA, and access decisions are recorded centrally for review.
• The proxy can be Datawiza-hosted or deployed in the institution's cloud, data center, or hybrid environment.

This is the same no-code MFA pattern for existing web applications used across commercial and public-sector environments, adapted to campus identity architecture and user populations.

A practical rollout for campus IT

1. Inventory the uncovered applications. Start with web applications that still rely on password-only access or separate credentials outside the campus IdP.
2. Prioritize by exposure and data sensitivity. Focus first on internet-facing portals, privileged administrative systems, student financial data, HR and payroll, and applications with high-impact transactions.
3. Choose the right identity mode. Use campus IdP MFA for managed employee and student populations; use built-in MFA where users should keep existing application identities.
4. Pilot one application. Validate login flows, headers or tokens, session behavior, audit events, and rollback before expanding the pattern.
5. Repeat application by application. Once the access-layer pattern is established, campus IT can extend the same controls to additional systems without starting a new connector project each time.

Secure the digital campus one application at a time

Higher education does not need to replace every important application before it can improve identity security. The faster path is to find the systems campus MFA and SSO do not reach, place a consistent enforcement layer in front of them, and close the highest-risk gaps first.

Book a demo to review one campus application, its user population, and the best MFA or SSO deployment pattern for it.