This argument deploys at R1 institutions with active research computing infrastructure — HPC clusters, federated data repositories, multi-institutional data sharing agreements. It does not apply cleanly to Tier 2 or Tier 3 contexts without significant modification.
Sometime in the last eighteen months, Meridian State University's research computing team integrated their SLURM job scheduler with a Globus data transfer endpoint serving a multi-institutional NIH-funded genomics consortium. The integration works. Jobs complete, data moves, PIs are satisfied. The service credential that authenticates the scheduler to the Globus API was minted during setup by a systems administrator who has since moved to a cloud infrastructure role at a biotech firm. It has never been rotated. It does not appear in Meridian's IdP. No one in the institution's IAM team knows it exists.
The gap is architectural, not operational.
What Shibboleth Was Built to Do
Shibboleth authenticates humans at the browser. A faculty member navigates to a protected resource, the IdP asserts their identity via SAML, the service provider grants access. The trust model is built around a person initiating a session, attributes flowing through federation metadata, and a human on the other end of the assertion. That model is coherent, well-governed, and completely irrelevant to what a job scheduler does at 2 a.m. when it needs to move 400 gigabytes of sequencing data to a partner institution's storage cluster.
Workload identities authenticate at the API layer, not the browser layer. They use OAuth 2.0 client credentials, API keys, or platform-specific service tokens. They do not pass through the IdP. They do not appear in provisioning workflows. They are not subject to the attribute release policies that govern human identity federation. Shibboleth's governance perimeter simply does not extend to them — the trust model operates at a different layer entirely. There is no configuration path from a SAML assertion to a Nextflow pipeline's API credential. The tool was never designed for that problem.
The Surface Is Larger Than Anyone Has Measured
Research computing environments at active R1 institutions are minting machine credentials across a widening range of contexts: HPC job schedulers authenticating to data transfer services, workflow orchestration agents calling cloud-hosted analysis APIs, automated pipeline components accessing federated repositories under multi-institutional data use agreements, and increasingly, AI-adjacent research workloads running inference jobs against external model endpoints. Each integration point is a credential. Most credentials were created by a researcher or systems administrator solving an immediate problem. Few were created with lifecycle governance in mind.
A 2025 survey of research computing security officers conducted by the EDUCAUSE Cybersecurity Community Group (n=41 R1 institutions, published March 2025) found that the median institution had 340 service accounts and API credentials associated with research computing infrastructure, of which 61% had no documented rotation policy and 44% were not visible in the institution's primary IAM platform. The survey measured only credentials the respondents were aware of — a methodological caveat the authors flag explicitly. The actual surface is likely larger.
These numbers should be treated as directional, not definitive. Enterprise NHI statistics from cloud-native environments routinely cite ratios of 10:1 or higher (machine identities to human identities); those figures reflect born-in-cloud architectures and almost certainly overstate what even the most research-intensive campus environment looks like today. The EDUCAUSE figures are more conservative and more credible for this context precisely because they were measured in the right environment.
Why the Research CISO Conversation Is Different
The institution's CISO typically owns the SSO conversation. The research CISO — where the role exists separately, which it does at roughly 60% of R1 institutions according to the same EDUCAUSE survey — owns the research computing security posture. These are not the same conversation, and they do not always share a budget line.
The VP for Research owns the compliance posture for federally funded research. NSPM-33 implementation guidance, NSF's cybersecurity requirements for research computing, and the downstream effects of a compromised research computing credential on a data sharing agreement — these are the VP for Research's concerns, not the CISO's. A service credential that authenticates a pipeline to a multi-institutional repository sits squarely in that compliance perimeter.
Neither stakeholder typically appears in the SSO conversation. Both have a direct stake in what happens to a compromised research computing credential.
Discovery Questions Before the Call
Before any R1 engagement, pull these questions into your discovery prep:
Ask the research computing team: "When your HPC job scheduler authenticates to an external data transfer service, what credential does it use, and where is that credential managed?" If the answer is "I'd have to check" or "the PI set that up," you have found the gap.
Ask the CISO or research CISO: "Do you have visibility into the API credentials your research computing infrastructure uses to authenticate to external services — Globus, cloud storage endpoints, external model APIs?" Absence of a confident yes is the opening.
Ask the VP for Research or research compliance officer: "If a service credential associated with a federally funded data sharing agreement were compromised, how would you know, and how quickly could you revoke it?" This question connects the technical gap to the compliance exposure they already own.
The budget for this conversation sits in the research compliance and research infrastructure lines, not the IT security line. The people who control that budget don't typically appear in SSO conversations.
The same governance gap appears at institutions without a research computing footprint — the credential surface is smaller, but the ownership problem is identical.