Yes — where a lab platform integrates with institutional identity, students sign in to their virtual environments with the same Microsoft account they use for email and Teams, through single sign-on against Microsoft Entra ID. The university keeps control: enrolment drives who can sign in, groups or roles decide who sees which module's labs, institutional MFA and conditional access apply automatically, and access ends when the account does. This guide explains the concepts an IT team needs to configure that well — authentication versus authorisation, SAML and OpenID Connect, claims, group mapping, lifecycle and failure planning — without turning into a portal walkthrough.
Can students use university Microsoft accounts to access cloud labs?
Where the platform supports it, yes — and it should be a default requirement in any lab evaluation. Single sign-on against Microsoft Entra ID (the identity service behind most UK universities' Microsoft 365 estates) means no separate lab passwords to issue, reset or leak; access that follows enrolment automatically; and your existing security controls — multi-factor authentication, conditional access — applying to the lab like any other institutional application.
The integration is conventional from Entra ID's point of view: the lab platform is registered as an enterprise application in your tenant, students authenticate with Entra ID, and the platform receives a signed token saying who they are. Everything else in this guide is about doing that simple arrangement carefully.
How do SAML and OpenID Connect fit?
SAML and OpenID Connect (OIDC) are the two standard protocols a service uses to trust an identity provider, and Entra ID supports both for enterprise applications. Conceptually they do the same job: the user is sent to Entra ID to sign in, Entra ID authenticates them under institutional policy, and the application receives a signed assertion (SAML) or token (OIDC) containing claims — statements about the user. SAML is the long-established enterprise pattern; OIDC is the more modern, web-native one.
For an IT team evaluating a lab platform, the protocol choice matters less than the questions around it: which protocol does the platform support against Entra ID, what claims does it need (next section), and is the integration a standard enterprise-application setup or something bespoke. Standard is good — it means your existing processes, conditional access and sign-in logs all work unchanged.
What claims does a lab platform actually need?
As few as possible — data minimisation is both good privacy practice and good engineering. A teaching-lab integration typically needs a stable unique identifier, a display name, an email address or username, and something to drive authorisation: group membership or a role. It does not need job titles, phone numbers, office locations or anything else the directory happens to hold.
One practical caution from Microsoft's own guidance: emitting all of a user's groups in the token runs into token-size limits for heavily-grouped users (a common condition in universities). Prefer emitting only groups assigned to the application, or use app roles — Entra ID's mechanism for defining application-specific roles and assigning users and groups to them — so the platform receives a small, meaningful set rather than a directory dump.
| Claim | Why the platform needs it | Notes |
|---|---|---|
| Unique identifier | Stable key for the user's environments and records | An opaque ID; not something that changes on name change |
| Display name | Showing lecturers whose environment is whose | Display only |
| Email / username | Communication and human-readable identity | Institutional address, not personal |
| Groups or roles | Deciding module access and staff permissions | Send only relevant groups — see the caution below |
| Everything else | — | Withhold by default; add only with a stated need |
Should every student be assigned, or only some?
Assign deliberately, not universally. Entra ID enterprise applications support assignment — requiring users or groups to be explicitly assigned before they can sign in — and for a lab platform that is usually the right posture: the modules using labs are known, so assignment via module or cohort groups keeps the sign-in population meaningful and the licence conversation honest. Opening the application to the whole tenant is simpler but means anyone with a university account can authenticate, leaving all gating to the platform.
Group-based assignment also answers the module question cleanly: a group per module or cohort (however your institution already models these) is assigned to the application and mapped to the right access inside the platform. Late enrolments and withdrawals then flow through ordinary group membership changes rather than lab administration.
How should lecturer and administrator roles be assigned?
Through groups or app roles, never by hand-editing individuals in the platform. The pattern: a small set of platform roles (student, lecturer, platform administrator), each mapped from an Entra ID group or app role assignment, so role changes are directory operations with your existing joiners-movers-leavers processes behind them. A lecturer added to the module-staff group gets teaching controls; removed, they lose them — no lab-side memory to go stale.
Keep the administrator set small and boring: named individuals, MFA-enforced, reviewed on a calendar. And resist service accounts as a convenience — a shared 'lab-admin' identity with a long-lived password is exactly the unmanaged credential SSO was meant to remove. Where the platform genuinely needs a non-human identity for integration, treat it as privileged: owned, secured with strong credentials, scoped minimally and reviewed.
How do MFA and conditional access affect lab access?
They apply automatically, and that is most of the point. Because students authenticate against Entra ID, your MFA registration and prompting policies, device and location rules, and risk-based controls all run at sign-in exactly as they do for email — the lab platform neither implements nor bypasses them. Institutions get consistent policy; students get no new authentication rituals to learn.
Two teaching-specific wrinkles are worth checking rather than discovering. First, timetabled sessions concentrate sign-ins: ninety students authenticating (and perhaps MFA-prompting) in the same five minutes is normal for labs and worth confirming behaves well. Second, conditional access rules written for office working — blocking unfamiliar locations, say — can surprise distance learners reaching labs from abroad; review the policies that will actually apply to lab cohorts before week one.
What happens when a student leaves a module — or the university?
Design both exits before launch. Leaving a module should be a group-membership change: the student drops out of the module group, loses the module's lab access, and their environments follow the module's lifecycle policy (retained through marking, then archived or destroyed). Leaving the university is the stronger case: the Entra ID account is disabled through your normal leaver process, which ends platform sign-in immediately — but the platform still holds environments and records, so agree what happens to those (grace period, export, destruction) as part of lifecycle policy rather than ticket-by-ticket.
The design principle: SSO makes access removal automatic, but resource clean-up remains a platform lifecycle job. The two together — identity-driven access plus module-driven environment lifecycle — are what keep a lab estate from accumulating orphans. Do not create parallel local accounts 'just in case'; they outlive their owners and defeat the model. The narrow exception is break-glass platform administration, covered below.
How should guest and external users be handled?
Occasionally a lab cohort includes people outside the institution — external examiners, visiting staff, partner-college students. Entra ID's guest model (B2B collaboration) can cover them: the external person is invited as a guest in your tenant, subject to your policies, and reaches the application like any assigned user. That keeps external access visible and revocable in the same place as everything else, rather than through side-door local accounts.
Treat guests as a policy question first: who may be invited, by whom, with what MFA expectations, reviewed how often. For most lab deployments the honest answer is that guests are rare enough to handle deliberately, case by case — the trap is only ever the untracked alternative.
What should an SSO pilot test?
Identity is one of the highest-value things a lab pilot can exercise, because its failures are cohort-wide and term-time. A readiness and testing checklist:
- The enterprise-application setup works end to end for a real student account — not just an IT test account
- Claims received match the minimisation table: enough to operate, nothing more
- Group or role mapping produces the right experience for a student, a lecturer and an administrator
- A brand-new student (created this week) can sign in — provisioning latency is a classic first-day failure
- Removing a user from the module group removes access, on the timescale you expect
- MFA and conditional access behave sensibly for the cohort's real locations and devices
- A timetabled-session sign-in surge behaves well
- Break-glass administration works with SSO deliberately bypassed — tested once, documented, locked away
- Sign-in failures produce comprehensible errors and a known support route
Fold these into the wider pilot structure in our pilot guide — identity is a stage-one, staff-only concern that must be settled before students are invited.
Read next: How to run a cloud lab pilot
How does Cloud Pulse work with Microsoft Entra ID?
Cloud Pulse can integrate with institutional identity providers, including Microsoft Entra ID, where an institution configures SSO — students and staff sign in to their teaching labs with existing university credentials, and the configuration is agreed during onboarding against your tenant's policies rather than imposed as a fixed pattern. Role separation inside the platform follows the model this guide describes: students see their own environments, lecturers manage their modules' labs, and administrators hold platform configuration.
The identity conversation is part of scoping and of any pilot: the claims, assignment and lifecycle questions above are exactly what gets walked through with your IT team. If student web hosting rather than lab environments is the service you are wiring to Entra ID, the Student Web Hosting answer centre has its own dedicated SSO guide.