Gartner’s How to Achieve the Minimum Viable AI Governance
Blog
Back to School, Back to Exposure? Higher Education Cybersecurity
Compliance
Endpoint Hardening
Exposure Management & CTEM
Risk Management
Unmanaged Devices
The new academic year is the university’s largest recurring change event. It is also the moment when unresolved exposure meets a fresh wave of users, devices, applications, permissions, and operational exceptions.
It's not so much that the industry has failed to detect the problem. It's that it struggles to convert detection into correction across an environment designed for distributed control and continual change.
Most institutions can already identify devices, scan them for vulnerabilities, and report which policies they violate. What's more difficult is determining which security state each device and identity should maintain, how to safely get there if it's not the current state, and preventing local decisions or incomplete lifecycle processes from quietly eroding things.
Behind that difficulty is a contested control plane in which central policy, departmental autonomy, operational exceptions, inherited infrastructure, and constant change all act on security state.
That contested control plane has two closely related dimensions. Device posture determines what a system is permitted to run, how it is configured, whether it is vulnerable, and what resources it can reach. Identity posture determines who or what can access those systems, under which privileges, and for how long.
Universities usually manage these as separate disciplines, but attackers experience them as one environment. A stale account becomes materially more dangerous when it can reach an unpatched workstation. A hardened endpoint remains exposed when an overprivileged identity can change its configuration or disable its controls.
Wake Us Up When September Ends
Most large enterprises experience change. Universities revolve around it.
The September surge lands on an environment that is already difficult to govern. A single institution may operate an enormous network spanning a central campus, satellite sites, residence halls, laboratories, libraries, athletics facilities, cloud environments, and affiliated healthcare operations.
IT teams prepare accounts, rebuild teaching labs, connect devices, update classroom technology, restore services, and absorb the annual surge in support demand. From a security perspective, it's a synchronized expansion of the institution’s attack surface.
New students arrive with unmanaged devices. Faculty and researchers adopt new tools for the term. Temporary staff and teaching assistants receive access. Returning users regain entitlements. Laboratories restart projects and connect specialized equipment. Departments request exceptions because teaching cannot wait for a lengthy approval cycle.
At the same time, graduates, transfers, former employees, and completed research collaborations leave behind accounts and permissions that may or may not have followed them out.
Further complicating matters is the fact that the IT architecture is typically cobbled together over decades through departmental purchases, research grants, expansions, new buildings, changing technology standards, and local decisions made under very different security assumptions.
On the same network, the university may need to protect student records, payment data, intellectual property, regulated health information, high-performance computing, laboratory systems, building controls, and specialized research infrastructure.
Few conventional enterprises combine public access, healthcare availability, sensitive research, critical infrastructure, and constant population churn under one administrative roof.
Beyond scale, the core challenge for higher education cybersecurity is reconciling conflicting operating conditions:
- Central security accountability without consistent central control
- Decades of technical debt alongside cutting-edge research infrastructure
- High availability requirements in clinical and campus operations
- Sensitive research targeted for commercial advantage, extortion, or state intelligence collection
- A population whose roles, affiliations, and access requirements change continuously
Bringing those disparate conditions somehow into balance to simultaneously achieve operability, availability, and security is no small task. In fact, it's downright Sisyphean. Which is probably why the UKs 2025 Cyber Security Breaches Survey found 91% of higher education institutions suffered breaches during the previous 12 months, compared with 43% of businesses overall. Among those education institutions affected, 30% experienced weekly attacks.
The same group reported account takeover at twice the rate of businesses overall, ransomware at two-and-a-half times the business rate, and denial-of-service attacks at more than seven times the business rate.
Those numbers speak volumes. Take a moment to let them sink in.
Even as I write this, I am reminded of the fact that my own social security number was compromised as a result of a University of Maryland database breach in 2014. At the time, I had already been several years removed from my time at the university.
Higher education institutions are not only trusted to shape millions of minds every year, but to safeguard their students' information. Unfortunately, it's become increasingly common for them to fall short.
The New Academic Year Stress-Tests the Shared Trust Fabric
In terms of operational risk, universities really are in a class all their own. They combine many of the most persistent challenges of healthcare and critical infrastructure operations while retaining their own unique complementary complexities.
Campus scale amplifies architectural inconsistency
University networks extend across thousands of rooms, multiple campuses, satellite facilities, remote users, cloud services, and partner environments. Endpoints range from centrally managed laptops to research workstations, teaching lab machines, kiosks, servers, virtual desktops, building systems, laboratory equipment, and devices managed by affiliated organizations.
Much of that infrastructure was built piecemeal. A control that works well in a recently modernized administrative environment may have little reach into a laboratory network designed fifteen years earlier. Every technology generation leaves behind systems, trust relationships, and management assumptions that the next generation must inherit.
Different departments may use different management systems, directory structures, operating standards, and exception processes. Attackers need only one usable path through those layers, while defenders must understand how every layer interacts.
Under those conditions, correction efforts are doomed to fail when ownership and management authority are overly fragmented.
The campus itself is a cyber-physical system
The endpoint estate does not stop at conventional IT. Universities operate enormous HVAC and lighting systems, building-management platforms, access controls, environmental sensors, energy-management infrastructure, laboratory freezers, scientific instruments, and specialized equipment with unusually long service lives.
New facilities and connected devices are layered onto older infrastructure that may never have been designed for remote administration or exposure to modern networks.
These systems carry consequences that are easy to miss in an asset inventory organized around employee computing. A configuration change to an ultra-low-temperature freezer or laboratory environmental-control system can damage years of research. A building-control outage can affect teaching, residence halls, clinical activity, or campus safety. A poorly governed maintenance connection can become a route from a vendor-managed system into the wider institutional environment.
Aggregate network visibility can show you risk, but in such a complicated interconnected environment, that information is not actionable on its own. To actually effectuate change, you need to know specifically which assets are involved, who owns them, what physical processes they support, what data or systems they can reach, and what happens if their states change.
In cyber-physical environments, ownership and operational dependency are security attributes, not administrative metadata. Hardening efforts will always fall short when asset context and operational consequences are poorly understood.
Academic healthcare turns disruption into a patient-safety question
Many universities maintain affiliate hospitals, clinics, medical schools, or research care facilities. When they do, they inherit the cybersecurity pressures and pitfalls of healthcare delivery organizations. Clinical endpoints and connected systems must protect regulated data while remaining available for the delivery of care.
A hardening action that interrupts authentication, clinical software, or a device dependency can have consequences far beyond user inconvenience.
Compliance requirements add weight, but availability changes the operating calculus. Security teams cannot rely on the choice between “apply the control” and “accept the risk.”
They need a third option capable of:
Validating the change against dependencies, deploying it gradually, verifying the result, and reversing it quickly if clinical operations are affected.
Without those confidence-building capabilities, security-focused changes will always be deferred.
Research makes universities intelligence targets
Universities hold research data that can compress years of scientific, military, medical, or commercial development into a single theft. The value is not confined to published findings.
Experimental data, grant proposals, source code, models, partner information, and early-stage intellectual property may be more valuable precisely because they are not yet public.
This changes the adversary model. The institution is not only defending against financially motivated criminals and opportunistic compromise. It may also face patient, well-resourced actors seeking persistent access to particular researchers, laboratories, or datasets. Those actors can exploit the openness and international collaboration that academic research relies on.
Some institutions even operate nuclear reactors for research purposes. In those cases, both the threat and the stakes are extraordinarily high. Good security is simply non-negotiable.
In 2018, the U.S. Department of Justice charged 9 Iranian nationals with cyber theft. According to the indictment, the campaign targeted more than 100,000 professor accounts and successfully compromised some 8,000 of them across 320 universities. Prosecutors alleged that at least 31.5 terabytes of academic data and intellectual property were stolen.
The target was research and intellectual property, accessed through trusted academic identities and the collaborative systems that universities encourage.
The fact is that by their very nature, higher education institutions involve themselves in work with direct national-security, public-safety, and critical-infrastructure applications. That paints a big target on the backs of universities and becomes a big problem when open collaboration mechanisms preserve attack paths.
The annual identity reset compounds management burdens
Most enterprises have joiner, mover, and leaver processes. Universities have all three at exceptional scale, with users who may hold several affiliations at once.
A person can be a student, employee, researcher, teaching assistant, hospital affiliate, alumnus, or contractor - sometimes simultaneously. Graduation, transfers, departmental changes, temporary appointments, research collaborations, and contract expiration all require access to be reassessed rather than simply switched on or off.
The return to school makes those lifecycle weaknesses palpable. Provisioning is urgent because users cannot work without access. Revocation is quieter. The person whose access should be removed may already be gone, while the account, token, mailbox, group membership, cloud role, or application grant continues to function.
For an institution that must revoke or materially change access for roughly one-fifth of its active population each year, even a small failure rate compounds quickly to create a staggering amount of exposure.
Universities need authoritative lifecycle control across identity sources, changing affiliations, downstream applications, local directories, cloud platforms, non-human accounts, and governed exceptions.
The objective is not merely to identify a deviation. It is to determine the correct state, execute the change safely, verify the result, and prevent unjustified access from returning.
Security State Is Where Policy Becomes Fact
Universities express security policy through both device baselines and access rules. A device may be expected to maintain a hardened configuration, run approved software, and receive critical patches. An identity may be expected to hold only the privileges justified by its current role, affiliation, and duration of access. In both cases, the policy has no security value until the intended state exists in the operational environment and can be shown to persist.
The start of term widens that gap. Operational teams are biased toward restoring service and onboarding users quickly. Findings that require coordination across central IT, security, facilities, research teams, clinical operations, or departmental administrators wait until the immediate pressure subsides. Some become tickets. Others become temporary exceptions.
Acceptable risks do not stay acceptable for long when controls depend on a future cleanup that operational teams rarely have the capacity to perform.
OS updates alter settings, application changes introduce new services and permissions, local administrators restore functionality by changing policy, and temporary exceptions linger. Role changes fail to propagate and tokens remain valid after the underlying relationship has ended.
These are usually classified as different problems, but they all follow the same pattern: the observed state has diverged from the institution’s intended state.
Periodic assessments expose the symptoms but do not control the process. A scan can show that a setting is wrong. A compliance dashboard can show that a device has deviated from policy. An identity review can flag access that may no longer be justified. None are capable of reliably confirming that the condition was corrected, that the correction was safe, or that it remained in force.
A stale account, unnecessary local administrator, exposed service, weak authentication setting, and unpatched application. The specific weakness or its position within your operational queue doesn't matter to the attacker. What matters is that he/she can find a way in and chain those weaknesses together to find a path to pay dirt.
Similarly, closing individual findings without validating the resulting path can leave the exposure intact. Moving from detection to correction therefore requires validated exposure elimination:
- Detect the deviation. Establish which device, account, entitlement, application, or control has departed from its intended state.
- Establish context. Determine ownership, role, exposure, dependencies, active controls, data access, operational consequences, and the justification for the current state.
- Choose the corrective action. Decide whether the appropriate response is patching, hardening, software removal, account disablement, privilege reduction, token revocation, a compensating control, or a governed exception.
- Execute safely. Validate the proposed change, test it against representative systems or user populations, deploy it in stages, and preserve a rapid reversal path where operational disruption is possible.
- Verify the resulting state. Confirm on the affected device and in every relevant identity or application system that the change completed, the exposure was removed, and legitimate activity still functions.
- Sustain the correction. Detect recurrence, reapply policy where appropriate, reassess access when affiliations change, and prevent temporary exceptions from becoming permanent exposure.
If those stages operate in separate tools and teams without shared context, the institution has a detection workflow connected to a correction workflow by administrative hope. Connecting those stages through a centralized oversight and execution platform turns endpoint hardening from a periodic project into a continuous control process.
Build and Measure Enforcement Around Operational Enablement
Just because a change is the right move from a hardening perspective doesn't mean it won't impair required functionality. It is often easier to get a handle of the situation from a security perspective than it is from an operational perspective. Unfortunately, security does not exist in a vacuum. Quite the contrary, security is only valuable to the extent that it prolongs and protects operations.
With that equation, uncertainty around the operational impact of changes will almost always result in inaction. To achieve real, resilient higher education security, decision makers need to change the equation by baking operational safety into the security architecture.
Start small with a representative pilot group. The pilot should include the dependencies and edge conditions most likely to fail in production. Validate the proposed action before execution, roll it out in phases, verify both security state and service health, and retain a rapid rollback path.
When a change cannot be applied, record the reason and compensating control as governed state rather than allowing an undocumented exception to become permanent.
Identity changes therefore require the same discipline as device changes: an authoritative owner, dependency awareness, staged execution where possible, downstream verification, and a controlled restoration path. Fear of access disruption cannot be a reason to preserve unjustified trust indefinitely.
For a university, “start small” should mean bounded and consequential, not convenient. Select a use case where correction removes material exposure and the asset owner can verify operational impact.
A defined research environment, one clinical device class, a building-system segment, a teaching-lab image, or an identity population with a clear lifecycle
Be sure to establish the baseline, correction path, rollback condition, owner, and success measure before expanding coverage.
Centralized control should not mean imposing identical configurations or access rules across the institution. It should mean operating one governance model for many explicit device and identity baselines.
A faculty laptop, public computer lab, research workstation, domain controller, building system, and clinical endpoint all require different technical states. Likewise, a student, researcher, teaching assistant, clinician, contractor, service account, and AI agent all require different access states. At the same time, those nuances should be determined and governed through the same decision structure:
- A defined owner, role, and authoritative source
- A device or access baseline appropriate to that role
- Documented exceptions with scope, justification, owner, and expiration
- Pre-execution checks for dependencies and operational impact
- Staged rollouts across representative devices or identity populations
- Post-change validation in the authoritative and downstream systems
- A tested rollback or access-restoration path
- Continuous monitoring for renewed drift or unjustified access
The sequence is deliberate: identify the critical assets, define the decision criteria, collect the evidence, execute the intervention, and prove the result.
Monitoring data on its own does not improve security any more than energy telemetry reduces consumption by itself. Value appears when reliable observation changes operational state.
This approach changes the relationship between Security and IT. Security no longer hands over an abstract finding. IT no longer receives a change request without the context needed to execute it. Both functions operate with a common dataset and operational frame of reference.
Momentum is key and the single most important measure of progress is the rate of risk removal compared to the rate of risk acquisition. If overall risk is trending down, even if slowly, you're in comparatively good shape. If it's holding steady or trending up, you'll have plenty of work ahead.
But mature organizations will not assess their security posture through any single measure of progress. They'll want to make sure they're removing the biggest, most accessible points of exposure first.
Tracking the debt balance and its age reveals whether the institution is removing accumulated exposure or merely processing the findings easiest to close.
These are not separate scorecards. Together, they show whether the institution can maintain control over the devices and identities from which attack paths are assembled.
These metrics expose the real bottleneck. If detection is fast but validated correction takes weeks, you know where to focus your efforts, your process refinements, and your investments.
This information should be paired with a running accounting of unresolved exposure that accumulates outside day-to-day metrics. In a university, this includes unowned assets, orphaned accounts, stale privileges, expired exceptions, unresolved drift, unpatched systems, unreviewed policies, and AI agents or integrations that were never retired.
Embracing Continuous Security-State Control
Every September brings a test of whether the university can absorb change without losing control of device state or identity state. To meaningfully improve their security posture, universities must stop managing findings and lifecycle events as separate queues. Instead, they need to continuously assure the state of the systems and identities through which institutional activity occurs.
That requires a closed loop across identity lifecycle governance, device configuration, vulnerability remediation, application control, exception management, and compliance validation.
Each discipline retains its specialist controls, but all must operate according to the same logic: detect divergence, establish context, execute the appropriate correction, verify the resulting state, and prevent recurrence.
Detection must preserve enough context to drive the right action. Correction must be safe enough to be executable in sensitive environments, verifiable enough to prove that risk changed, and persistent enough to survive drift.
The institution must also preserve local flexibility without surrendering central accountability.
To make that happen, operators must first identify whether the institution is eliminating exposure faster than they create it.
They also need to identify the weakest links in their security chains - those areas most likely to undermine hardening efforts.
- Is the inventory unreliable?
- Are permission baselines missing?
- Is drift detected but left open because remediation cannot be validated or reversed?
- Can sensitive data move through AI tools without technical control?
- Does governance stop at written policy?
Do not begin with a campus-wide transformation. Choose one high-consequence control path. Name its owner, define its authoritative state, document the exception logic, and establish one measurable correction objective.
During the first 90 days of the academic year, prove that the institution can detect divergence, correct it safely, verify the result, and prevent recurrence. Then apply the operating model to the adjacent control plane.
Universities will always contain heterogeneous systems, distributed ownership, overlapping affiliations, and justified exceptions. Good security doesn't aim to change any of those underlying facts. It looks to navigate them more effectively and more efficiently. In practice that means maintaining continuous and well-bounded enforcement, verification, and trust controls.
FAQ
Why is higher education cybersecurity especially difficult?
Universities combine sprawling networks, decades of inherited infrastructure, decentralized administration, open academic environments, high identity churn, specialized research systems, and strong availability requirements. Some also operate hospitals, clinical facilities, and critical research infrastructure. The challenge is not simply detecting risk across this environment. It is maintaining appropriate security and access controls without eliminating the flexibility required for teaching, research, patient care, and campus operations.
Why are orphaned accounts particularly dangerous in higher education?
Graduation, transfers, role changes, temporary research appointments, and overlapping student or employee affiliations make university identity lifecycles unusually complex. When revocation processes miss an account or entitlement, the access can remain technically valid after its justification expires. These misses accumulate across annual cohorts, creating access debt that can provide attackers with durable entry points into institutional systems.
What is configuration drift in a university environment?
Configuration drift occurs when a device moves away from its approved security baseline. It can result from software updates, local administrative changes, new applications, temporary exceptions, policy conflicts, or routine support activity. Because campus systems change constantly, drift must be treated as an expected operating condition rather than an occasional anomaly.
How can universities harden endpoints without disrupting users?
Safe hardening depends on contextual baselines, dependency checks, representative pilot groups, staged rollout, post-change verification, and rapid rollback. Institutions should govern legitimate exceptions explicitly instead of either forcing an unsafe change or leaving the deviation undocumented.
Is endpoint monitoring enough to prevent configuration risk?
No. Monitoring establishes that a device has departed from policy. Risk falls only when the device is safely corrected, the resulting state is verified, and the control remains enforced. Monitoring is one stage of the control loop, not the outcome.
Where should a university begin improving its cybersecurity posture?
Universities should begin where three weaknesses intersect: high operational consequence, incomplete coverage, and a correction process that stops at detection. That may be a research environment with persistent configuration drift, a clinical device population with unresolved vulnerabilities, or an identity group with unreliable access revocation. Define the intended security state, assign an accountable owner, establish how exceptions and dependencies will be handled, and select one measurable correction objective. The initial goal should not be broader visibility. It should be proving that the institution can detect a deviation, correct it safely, verify the resulting state, and prevent it from recurring. Once that closed loop works in one high-consequence area, the same operating model can be extended across additional devices, identities, and campus environments.
About Author
