Estimated reading time: 4 minutes
To help research and higher education (R&E) institutions navigate challenges in using cloud technologies for research, the Internet2 CLASS program launched the Secure Research Environments series in early 2026.
The series is split into three distinct phases that cover the different stages of institutional planning and execution.
The second phase — the Design phase — focused on secure research design subjects. Over the course of eight webinars and workshops, we covered topics like project scope, common enclave patterns, real-world implementations, security controls, and how major cloud providers approach building secure research environments.
Catch Up on the Secure Research Environments Series
If you’d like to review recordings or slides from any session, please contact CLASS
Scoping and the Common Enclave Patterns
The Design phase opened on April 7 with the Patterns for Secure Research Enclaves webinar.
The webinar centered around the idea that your scope is not a network diagram. What are we responsible for demonstrating compliance over? That answer defines your audit surface, and precise scoping shrinks it.
Control inheritance is closely related. Leaning on a cloud provider’s or campus IT’s controls reduces your implementation burden, but not your accountability. If an inherited control fails an audit, it’s your audit that fails.
From there, the webinar laid out a taxonomy of recurring enclave patterns, each analyzed across isolation, compute, and data egress:
- VDI “safe havens”
- High-power compute desktops
- Shared data lake with private analysis sandboxes
- Secure HPC/batch clusters
- Secure web-app hosting
- A full “cloud with guardrails” model
There’s no single winner. Whichever you choose, every secure research environment rests on the same foundation — a defined sandbox boundary, an inheritance strategy, an egress-control philosophy, and a cross-cutting guardrail layer of identity, logging, and network controls.
Most institutions compose several patterns under shared governance. The pattern-by-pattern walkthrough is well worth watching the webinar recording.
What It Looks Like in the Real World
On April 21, the webinar session Real World Secure Research Environment Implementations and Lessons Learned actualized the patterns from the prior session in real-world practice.
Secure-enclave operators from North Carolina State University, the San Diego Supercomputer Center, Vanderbilt University, and Cornell University walked through as-built secure research environments (across AWS, AWS GovCloud, and Azure) and what they would change.
For all their differences, their secure research architectures rhymed. Most run the enclave as a self-contained island, with everything in scope and minimal campus dependencies. Access is funneled through a VDI or VPN, keeping researchers’ laptops out of scope. And for consistency, teams are consolidating on Terraform.
A few lessons stood out:
- The boundary lives in your documentation: Your real boundary is the written account of how you protect the data and whether your controls are actually configured the way the paperwork claims.
- Own every component: One institution nearly lost a VPN that the networking team didn’t realize was load-bearing for the research environment, and learned to document controls as “this version or higher” rather than pinning exact versions that block patching.
- “Build” is a sustained commitment: After years of operating enclaves, one panelist offered simple advice. Unless you have a strong strategic and financial reason to build, seriously weigh buying or renting. The people, infrastructure, and licensing costs never stop.
- Shared tenants multiply coordination: One institution’s choice to use the central university tenant pulled in eight different units and surfaced services (Entra ID, Defender, Sentinel) with no clean boundaries. This made early coordination and change-management governance essential.
Closing the Gap Between Implementation and Audit
A hands-on security controls workshop on May 5, From Interpretation to Review, addressed the important and often underestimated step of closing the distance between what you configure and what an auditor expects to see.
Through a Red Team/Blue Team exercise, participants practiced the full lifecycle of a control, interpreting an ambiguous requirement, documenting it, and then defending that documentation under audit.
There is often no universal correct interpretation. What matters is that yours is defensible, documented, and supported by leadership, and that what you write down actually matches what you’ve implemented, because that gap is the first thing a real assessor probes.
What’s Next
The Design phase of the Secure Research Series is now complete, and the series now moves into its Implementation phase. This phase shifts from exploring “what is possible” to action-oriented, deep-dive sessions.
The first webinars in this final phase are scheduled, and registration is open. More sessions will be announced as they are confirmed, so please check back periodically.
If you need some extra motivation to attend, institutions that participate in all sessions within a phase receive one hour of personalized consulting (up to three hours across all three phases) with experienced community members to help launch your secure research initiative.
If you haven’t already, join us for the Secure Research Environments series so you don’t miss what’s ahead.
ICYMI
< Back to Internet2 News