Research Institution Identity Security Guide: Federated Access, Research Data and Export Controls

Research institutions run some of the most open identity environments anywhere, yet they hold controlled data, export-controlled technology and unpublished results that foreign intelligence services and criminals actively seek. A single researcher may hold a home university account, federated logins to dozens of collaboration services, a national supercomputing allocation, SSH keys on lab clusters and a separate account on a sponsor's portal. This guide covers identity security for universities, research institutes and national laboratories: federated access through national federations and eduGAIN, assurance and incident response signalling (REFEDS MFA, Sirtfi), protecting sensitive research data and CUI, US export controls (EAR and ITAR deemed exports) and research security programmes under NSPM-33. It is written for identity architects, research computing teams, information security officers and research security leads. It builds on the Education Identity Security Guide, which covers student and staff lifecycle at scale, and is not legal advice.

Key takeaways

• Federation is the front door. eduGAIN interconnects 84 national federations with more than 6,600 identity providers, so a compromised home account can reach services across the world; your IdP's assurance signals matter to everyone who trusts it.
• Signal MFA honestly and consistently. The REFEDS MFA Profile (https://refeds.org/profile/mfa) lets services require MFA through SAML AuthnContextClassRef or the OIDC acr claim, and an IdP must not assert it if any factor was bypassed.
• Commit to cross-institution incident response. Sirtfi (v2 entity attribute https://refeds.org/sirtfi2) tells partners you will cooperate on operational security, incident response, traceability and user rules when a federated account is abused.
• Controlled data needs a controlled enclave. CUI, export-controlled technology and sensitive health data should sit in environments with their own access rules, not in the general-purpose research estate.
• Granting access can be an export. Under the EAR a release of controlled technology or source code to a foreign person in the US is a deemed export, and under ITAR providing access information that lets a foreign person view unencrypted technical data is a release.

Why research identity is different

• Openness by design: collaboration across institutions and countries is the point of research, so blanket geo-blocking or closed directories break legitimate work.
• Many identity types per person: staff, students, visiting researchers, emeriti, honorary appointments, industry partners, and people who are all of these at once. Affiliation changes faster than HR systems record.
• Decentralised IT: departments and labs run their own clusters, instruments, wikis and cloud accounts, often with local accounts outside central identity.
• Long-lived machine credentials: SSH keys, data transfer service accounts, instrument controllers and workflow tokens that outlive the project or postdoc who created them. See the SSH Key Management Guide.
• High-value targets: unpublished results, clinical data and dual-use technology attract state actors who favour valid accounts (ATT&CK T1078) and password spraying (T1110.003) against cloud tenants (T1078.004). See the Password Spraying and Credential Stuffing Defence Guide.

Federated access: eduGAIN, national federations and REFEDS

National research and education federations publish signed SAML metadata about their member identity providers (IdPs) and service providers (SPs); eduGAIN aggregates that metadata between federations so a researcher can log in to a service in another country with their home account. eduGAIN's live statistics list 84 federations, 6,652 IdPs and 4,130 SPs. Trust depends on each member keeping its metadata, contacts and security practices honest. In the US, InCommon's Baseline Expectations (version 2, adopted December 2021) set those minimums for its participants.

Implementing the REFEDS MFA Profile

• SAML: SPs request the profile in <RequestedAuthnContext>; IdPs return it in <AuthnContext> with AuthnInstant set to the earliest authentication in the SSO session that met the profile. With ForceAuthn, the IdP should re-run all factors or return an error.
• OpenID Connect: RPs request the URI as an essential acr claim (the profile says not to use acr_values for this) and read auth_time; prompt=login and max_age should trigger fresh authentication.
• Scope: the profile is for inter-organisational federated login. Do not reuse it as your internal MFA policy flag, because internal rules may diverge.
• Prefer phishing-resistant factors: the profile itself puts active man-in-the-middle attacks out of scope, so it does not guarantee phishing resistance. For administrators, research computing staff and anyone with access to controlled data, use FIDO2 security keys or passkeys. See the Phishing-Resistant MFA Guide.

Attribute release and authorisation

• Minimise: release the R&S bundle to R&S services and nothing more by default; licensed content services usually need only an entitlement or affiliation.
• Keep affiliation current: eduPersonScopedAffiliation values (faculty, staff, student, member, affiliate) are used by SPs for authorisation; a stale "member" value after someone leaves grants access across the federation.
• Virtual organisations: large collaborations manage their own group membership on top of home identities. Treat the collaboration's membership service as an authorisation system with owners and reviews. See the Authorisation Models Guide.
• Federation risks: a federated SP trusts every IdP in the aggregate unless it filters. Services hosting sensitive data should accept only IdPs that assert the MFA profile and Sirtfi, or restrict to named institutions. See the Federation and Trust Relationships Guide and the SAML Security Guide.

Protecting research data by sensitivity

A single policy for the whole research estate either blocks open science or under-protects controlled work. Tier environments by the data they hold and apply identity controls to match.

• CUI on campus: when a federal contract includes DFARS 252.204-7012 or similar clauses, the systems handling CUI must meet NIST SP 800-171, including multi-factor authentication (03.05.03 in Rev. 3) and least privilege (03.01.05). Universities usually do this in a separate enclave rather than raising the whole campus. See the NIST SP 800-171 and CMMC 2.0 Guide and the CUI Guide.
• Enclave identity: federating the enclave to the campus IdP is convenient, but it makes the campus IdP part of the security boundary. Many institutions use separate enclave accounts or a dedicated IdP instance with stricter registration.
• Classification first: PIs cannot protect data no one has classified. Make sensitivity a field in the project or data management plan. See the Data Classification Guide.

Export controls and deemed exports

US export controls turn some routine identity decisions, such as adding a visiting scholar to a group, into regulated acts. Work with the export control office; identity teams supply the mechanism, not the legal determination.

• Attributes for decisions: store a "technology control plan" membership or export-cleared flag in the directory, set only by the export control office, and use it in authorisation rules for controlled projects.
• Visitors and dual roles: sponsored visitor accounts must carry a host, an end date and the export review outcome. The Contractor Identity Lifecycle Guide covers sponsored accounts in depth.
• Key custody: for encrypted storage of ITAR data, the identity that can access keys is the control; restrict key access to authorised US persons or licensed individuals.

Research security programmes

NSPM-33 (signed 14 January 2021) directs US funding agencies to strengthen protection of federally funded research, and requires institutions receiving more than $50 million a year in federal science and engineering support to certify that they operate a research security programme. The CHIPS and Science Act of 2022 added annual research security training for covered individuals, and NSF Important Notice 149 introduced a training requirement effective 2 December 2025. In the UK, the NPSA Trusted Research materials (guidance for academia, senior leaders and an implementation guide) address similar risks.

• Where identity fits: research security programmes rely on knowing who has access to what. Accurate affiliation, sponsorship and access review data from the identity system is the evidence base.
• Foreign travel: issue loaner devices with fresh credentials for high-risk travel and review sign-ins during and after the trip; revoke tokens on return.
• Insider risk: monitor bulk downloads from sensitive projects and departures of staff with access to controlled data. See the Insider Data Theft Guide.

Research computing and non-human identities

• HPC and clusters: link cluster accounts to the institutional identity so leavers are removed; prefer short-lived SSH certificates issued after federated MFA over static authorised_keys files.
• Data transfer and workflow tokens: long-lived tokens for data movers, instruments and pipelines need owners, scopes and expiry. Store them in a vault. See the Secrets Management Guide.
• Cloud research accounts: grant-funded cloud accounts are often created on a personal card and root credentials stay with a postdoc. Bring them under the institution's organisation structure, enforce MFA on root and use workload identity federation for pipelines. See the Workload Identity Federation Guide.
• Code repositories: research code on public hosting often leaks API keys and cloud credentials. Enable secret scanning on institutional organisations.
• Learning platforms and SaaS tokens: integration tokens with broad scope are a target; the Canvas Instructure breach shows how one privileged platform token exposed data across many institutions.

Implementation roadmap

1. Inventory obligations and data: list contracts with CUI, EAR or ITAR clauses, regulated health projects and sponsor confidentiality terms; record which systems hold the data.
2. Tune the IdP: enforce MFA for all staff and researchers, phishing-resistant for privileged and controlled-data users; disable legacy authentication; keep affiliation attributes current from HR and student systems.
3. Signal to the federation: implement the REFEDS MFA Profile, register Sirtfi with your federation, publish a working security contact and test it.
4. Build or confirm enclaves: move CUI and export-controlled work into environments with separate identity boundaries and nationality-aware authorisation set by the export control office.
5. Pilot access controls: start with one controlled project; run conditional access in report-only mode, review blocked sign-ins with the PI, then enforce. Keep a documented rollback (policy disable plus break-glass account) for each change.
6. Bring research computing in: link cluster and cloud accounts to central identity, replace static SSH keys with short-lived certificates, vault workflow tokens.
7. Review and evidence: project access reviews at milestones and at least annually, visitor account expiry, and reporting to the research security programme.

Large versus small institutions: a research-intensive university above the NSPM-33 threshold needs a formal programme, a dedicated CUI enclave and identity data feeding research security reporting. A small institute with occasional controlled projects can often use a managed enclave or a sponsor-provided environment, focus on strong MFA and federation hygiene, and rely on project-level access lists maintained with its export control adviser.

Detection and measurement

Log IdP authentications including the authentication context asserted, MFA events, attribute release decisions, group changes on controlled projects and enclave sign-ins. Alert on password spraying patterns, impossible travel for controlled-data users, bulk downloads, new OAuth consents and federated sign-ins to sensitive SPs from IdPs that do not assert MFA. Map monitoring to NIST CSF DE.CM-03.

• MFA coverage: percentage of active accounts enrolled in MFA, and percentage of controlled-data users on phishing-resistant MFA.
• Federation signalling: percentage of sensitive SP logins with the REFEDS MFA context asserted.
• Visitor hygiene: percentage of sponsored and visitor accounts with a host, end date and export review recorded.
• Leaver speed: median time from end of affiliation to removal from controlled projects and clusters.
• Machine credentials: percentage of research SSH keys and tokens that are short-lived or vaulted.
• Sirtfi readiness: time to respond to a test message sent to the published security contact.

Framework mapping

ATT&CK techniques to test against: T1078, T1078.004, T1110.003, T1566, T1621 and T1567 (exfiltration over web service).

Common failure patterns

• Stale affiliations: former students and staff still asserted as "member", keeping access to federated services and licensed resources.
• Asserting MFA that did not happen: IdPs that send the MFA context after a remembered-device cookie, undermining every SP that relied on it.
• Controlled data in the open estate: export-controlled drawings or CUI on a departmental share or personal cloud folder, with access granted without export review.
• Orphaned research credentials: SSH keys and cloud root accounts belonging to researchers who left years ago. The Snowflake breach showed how infostealer credentials on accounts without MFA unlock data stores at scale.
• Dead security contacts: Sirtfi asserted but the contact address unmonitored, so partners cannot report a compromised account.

Practitioner checklist

• Enforce MFA for all staff and researchers, phishing-resistant for privileged and controlled-data users.
• Implement the REFEDS MFA Profile correctly in SAML and OIDC, and never assert it after a bypassed factor.
• Register Sirtfi with your federation and test the published security contact quarterly.
• Release the R&S bundle only to R&S services and keep eduPersonScopedAffiliation current.
• Tier research environments by data sensitivity and place CUI and export-controlled work in enclaves.
• Store export review outcomes as directory attributes set only by the export control office and use them in authorisation.
• Give every visitor and sponsored account a host, end date and review.
• Link HPC and research cloud accounts to central identity, and replace static SSH keys and long-lived tokens.
• Feed identity and access data into the research security programme.

Standards and references

• REFEDS: Multi-Factor Authentication Profile
• REFEDS: Security Incident Response Trust Framework for Federated Identity (Sirtfi)
• REFEDS: Research and Scholarship Entity Category
• GÉANT: About eduGAIN
• eCFR: 15 CFR 734.13 Export (Export Administration Regulations)
• eCFR: 22 CFR 120.56 Release (International Traffic in Arms Regulations)
• NIST: SP 800-171 Rev. 3, Protecting Controlled Unclassified Information
• NSF: Research Security

Related NHI Mgmt Group resources: Education Identity Security Guide · NIST SP 800-171 and CMMC 2.0 Guide · Federation and Trust Relationships Guide · Insider Threat and Identity Guide. This guide summarises US export control, NSPM-33 and NIST SP 800-171 identity considerations for research institutions and is not legal advice.