Estimated reading time: 4 minutes
In early 2026, the Internet2 CLASS program launched the new Secure Research Environments series. The three-part series, comprising webinars and workshops, was built to help research and higher education (R&E) institutions navigate secure research and compliance in the cloud.
The series is split into three distinct phases that cover the different stages of institutional planning and execution.
The second phase of the series, the Design phase, featured eight workshops and webinars around secure research environment topics, including implementation, secure controls, and common enclave patterns.
Four of those were deep-dive workshops from three major cloud providers — AWS, Microsoft Azure, and Google Cloud — and Kion, a platform for governing sensitive workloads.
At each workshop, we asked the vendors to answer the following questions for attendees:
- How do you design a scalable sandboxing architecture?
- Where do your compliance artifacts live, and how do we use them?
- Why does this matter even if only one lab at our institution has these needs?
Catch Up on the Secure Research Environments Series
If you’d like to review recordings or slides from any session, please contact CLASS.
AWS
The AWS team presented a way to solve compliance once and centrally, rather than lab by lab: an “invest once, scale many” architecture built on the open-source Landing Zone Accelerator (LZA) and packaged as a prescriptive Secure Research Environment reference architecture. Out of the box, it ships more than 85 technical controls mapped to NIST 800-171, CMMC Level 2, and HIPAA, so institutions start from a compliant baseline instead of building one.
Three supporting pieces rounded out the picture:
- A multi-account structure keeps CMMC and HIPAA workloads in separate organizational units.
- Service Control Policies are the strongest preventive guardrail. They deny actions regardless of individual permissions, even for the root account.
- AWS Artifact is where compliance artifacts live. The Control Implementation Summary and the Customer Responsibility Matrix show who is responsible for which control.
Microsoft Azure
Microsoft presented its design patterns for a “Trusted Research Environment,” an approach that keeps sensitive data under institutional control.
In the workshop, attendees stood up a compliant baseline and worked through three building blocks:
- A hub-and-spoke network architecture that isolates sensitive workloads
- Automated deployment templates that provision the baseline environment
- The Service Trust Portal, where Azure’s compliance artifacts and SSP source material live
A live walkthrough showed how to bring those pieces together.
Google Cloud
Google framed secure research environments as modern “Data Safe Havens” and focused on its data services. The centerpiece of the architecture was BigQuery Data Clean Rooms, which let multiple parties join and analyze data without copying or moving it. Egress and analysis rules are enforced at query time.
Layered on top was a perimeter and data-protection toolkit:
- VPC Service Controls to draw virtual security perimeters against exfiltration
- Context-aware access to gate access by identity and context
- Confidential Computing and Confidential Space to keep data encrypted even while it is being processed
- Sensitive Data Protection for discovery, de-identification, and re-identification-risk analysis
On the compliance side, Google pointed to Assured Workloads, which enforces data-residency and compliance-control requirements, and to the compliance reports it publishes for audit evidence.
Kion: Managing It All Across Clouds
Kion isn’t a cloud platform of its own — it is a platform for managing multiple clouds from one place.
The Kion team held the last of the four vendor workshops, which addressed the reality that many institutions require multiple cloud platforms in their research environments.
In a hands-on lab, participants worked in a dedicated AWS account provisioned for the session. Participants saw how a governance layer keeps configuration consistent and secure for sensitive workloads across AWS, Azure, and Google Cloud.
The workshop showed how the tool automates that process in three steps:
- Detect compliance drift
- Fix it
- Prevent it from recurring (and apply it uniformly, no matter which cloud a workload runs in)
Because Kion is hosted in a customer’s cloud environment, it’s important to reference the cloud provider’s documentation for compliance artifacts.
Three Approaches, One Shared Foundation
The three cloud providers share plenty of common ground, including a shared-responsibility model you inherit from but must validate, automated guardrails, and deliberate egress control.
They differ mainly in emphasis:
- AWS offers a prescriptive multi-account blueprint.
- Azure is a portal-and template-driven trusted environment.
- Google has a data-centric clean-room model.
Kion sits one level up, helping institutions keep all of that consistent when their research spans more than one cloud.
What’s Next
With the Design phase now complete, the Secure Research Environments series now moves into its Implementation phase. This final phase shifts from exploring “what is possible” to action-oriented, deep-dive sessions.
The first sessions are scheduled, and registration is open. More sessions will be announced as they are confirmed, so please check back periodically.
As a reminder, 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