The rep said "modernize your identity infrastructure" in the first five minutes. The two architects in the room exchanged a look. The meeting ended twenty minutes early, and the follow-up email went unanswered for three weeks. That's a closed door — and it closed the moment Shibboleth heard itself described as a problem to be solved.
What you're actually selling in this scenario looks different, and so does how you sell it.
The Only Credible Entry Point
Okta federates alongside a Shibboleth IdP. Technically accurate, strategically essential, and the only frame that survives contact with a campus architect who has spent four years tuning attribute release policies and knows exactly how their InCommon metadata aggregate works.
The architecture is straightforward enough to explain in a discovery call without a whiteboard. Shibboleth continues to handle what it handles: SAML assertions to InCommon-federated service providers, authentication for the research collaboration fabric, the eduPerson attribute release that the library's database vendors and the NSF's data-sharing portals depend on. Okta sits alongside it, extending the identity surface to the applications Shibboleth can't reach natively — OIDC-only SaaS platforms, cloud infrastructure consoles, the lifecycle management layer that Shibboleth's architecture was never designed to provide. The two systems exchange trust through standard federation metadata. Neither replaces the other.
Say this in a discovery call and something specific happens: the architects stop defending and start asking questions. That's the conversation you want.
What you need to be able to say without stumbling: Okta can act as a downstream IdP that receives authentication from Shibboleth — Shibboleth authenticates the user, passes the SAML assertion, and Okta handles downstream app federation, lifecycle events, and policy enforcement. Alternatively, Okta can serve as the primary IdP for the applications it manages while Shibboleth continues as the IdP for InCommon-federated SPs. The specific topology depends on what the institution is trying to govern. The InCommon trust fabric stays intact. The research collaboration infrastructure stays intact. The architects' four years of configuration work stays intact.
Don't lead with the topology. Lead with the outcome.
"Your InCommon federation doesn't move. We're adding governance surface, not replacing authentication infrastructure."
Reading the Room Before You Say Anything Else
The maturity state of the institution determines everything about which version of this conversation you're having. Get this wrong and the coexistence frame won't save you.
Tier 1 signals — R1s and large research universities: Listen for language about federal program officers, sponsored research compliance, or anything involving the words "research security." If the CISO is now reporting to the provost or the VP for Research rather than the CIO, that's a structural signal that identity has become a risk conversation at the executive level. If they mention NSPM-33 (the National Security Presidential Memorandum on protecting federally funded R&D, implementation guidance updated through 2025 — verify current status against NSF and OSTP guidance before citing in a call), they are telling you that access governance for research systems is now a compliance obligation, not an IT preference. If they had an incident in the last eighteen months, they are not asking whether to extend their identity governance. They are asking who can help them do it without breaking the research computing environment they've spent a decade building.
At a Tier 1, the capability gap argument lands. The compliance pressure argument lands harder.
Tier 2 signals — mid-size institutions, often a two-person IAM team: Listen for "it works fine," "our team built it," and "we don't have the budget to replace it." These are expressions of institutional survival instinct, not objections to Okta. A two-person IAM team that has kept Shibboleth running through two major version upgrades and a pandemic-driven remote access scramble has earned the right to be proud of that infrastructure. They are not wrong that it works. They are not wrong that replacing it would be a project. What they cannot see from inside the server room is the governance surface that doesn't exist — the lifecycle events that aren't being captured, the service accounts that aren't being managed, the adaptive policy layer that isn't there.
At a Tier 2, don't lead with capability gaps. Lead with "what would you do with the time you spend on Shibboleth maintenance if you didn't have to spend it." The capability gap argument comes later, and only after you've established that you're not there to tell them they've been doing it wrong.
What Shibboleth's Architecture Cannot Do
These are structural limitations, not configuration failures. This distinction matters enormously in the room. Say "Shibboleth can't do X because it's not configured correctly" and you've insulted the architects and you're wrong. Say "Shibboleth's architecture wasn't designed for X, which is why the community has always relied on adjacent tooling for that function" and you're accurate and you sound like someone who has actually read the project documentation.
Automated lifecycle management. Shibboleth is an authentication and attribute release system. It has no native provisioning or deprovisioning capability. When a research fellow's appointment ends, Shibboleth does not know. When a graduate student's enrollment status changes, Shibboleth does not act. The institution's directory — typically Active Directory or LDAP — is the authoritative source, and Shibboleth reflects whatever state that directory is in. The absence is an orchestration layer that connects HR events, enrollment events, and research appointment changes to access state. That gap exists regardless of how well Shibboleth is configured, because Shibboleth was not designed to close it.
At a Tier 1 with NSPM-33 exposure, this gap is a compliance finding waiting to happen. Frame it that way: "When your federal program officer asks how you ensure that access to controlled research data terminates within 24 hours of a personnel change, what does your current answer look like?" At a Tier 2, frame it as operational risk: "How many service accounts in your environment do you have full visibility into right now?"
Adaptive access policy. Shibboleth's authentication decisions are static at the point of configuration. The IdP can enforce MFA requirements and attribute-based access rules, but it cannot evaluate real-time risk signals — device posture, behavioral anomalies, network context — and adjust authentication requirements dynamically. This reflects the project's design priorities: Shibboleth was built to solve federation trust, not risk-based authentication. The limitation becomes consequential when the institution needs to enforce step-up authentication for access to sensitive research data based on where the request is coming from or what the user has been doing in the last hour.
NHI governance. Non-human identities — service accounts for HPC job schedulers, API credentials for research data repositories, machine identities for automated pipeline components — are invisible to Shibboleth's architecture. The IdP manages human authentication. It has no framework for issuing, rotating, auditing, or revoking machine credentials. In a research computing environment running multiple cloud platforms and a mix of on-premises HPC and cloud-burst workloads, the NHI surface can easily exceed the human identity surface by an order of magnitude. A 2024 survey by the Identity Defined Security Alliance (IDSA) found that organizations managing research-adjacent workloads reported NHI counts averaging 45 non-human identities per human user — a figure that campus IAM teams consistently underestimate because the identities were provisioned outside the IAM workflow entirely. [Note to field: this statistic is from IDSA's 2024 NHI research; verify current version and methodology before citing on a call.]
At a Tier 1 facing NSPM-33 scrutiny, NHI governance is the fastest-moving compliance gap in the portfolio. At a Tier 2, it's a risk they may not have named yet — which means your job is to help them name it, not to tell them they have a problem.
The Compliance Pressure Play (Tier 1 Only)
NSPM-33 and its implementation guidance from OSTP and the federal research agencies have created a specific obligation at R1 institutions: access controls for federally funded research must be demonstrable, auditable, and responsive to personnel changes. The obligation is not new, but the enforcement posture has sharpened since 2023, and institutions that received letters from federal program officers about research security compliance are now under active pressure to show their work.
Shibboleth's architecture does not produce the audit trail that satisfies this obligation. It authenticates. It releases attributes. It does not maintain a lifecycle event log that connects a personnel action to an access change and timestamps the gap between them. That log is what a federal auditor is going to ask for.
Open with the question before the product: "If your sponsored research office had to demonstrate to NSF that access to controlled project data was terminated within 24 hours of a PI's departure, where does that evidence come from today?" Let the room answer. Their response will tell you whether you're in a compliance conversation or an IT conversation, and those conversations have different buyers.
What You Don't Contest
Shibboleth's no-vendor-lock-in argument is real. The institution owns the configuration, the metadata, the attribute release policies. There is no contract renewal, no per-user pricing, no vendor roadmap dependency. For an institution that has been burned by enterprise software that changed pricing mid-deployment or deprecated a feature that the institution had built a workflow around, this is not a trivial concern. Acknowledge it plainly.
The community trust is earned. The Shibboleth Consortium and the InCommon community have maintained a trust fabric for higher education federation that has worked reliably for two decades. Campus architects who have contributed to that community, attended Internet2 TechEx, and helped debug metadata issues for peer institutions are not going to respond well to a rep who treats that history as a liability. It is the foundation that makes the coexistence architecture possible.
What the no-lock-in argument costs is maintenance debt and a capability ceiling. Customization control is real, but it comes with a staffing assumption: someone on the team has to own the configuration, track the version upgrades, manage the metadata refresh process, and stay current on the security advisories. At a Tier 2 with a two-person IAM team, that person is doing this work on top of everything else. Shibboleth is good — the question is what the institution is trading to keep it running at the level it needs to run, and whether that trade makes sense as the identity surface expands beyond human users and beyond the InCommon federation perimeter.
Say this honestly. The tradeoff is real on both sides, and the buyer will trust you more for naming both sides than for pretending otherwise.
What We Need From the Field
This playbook is a working document. Two things would sharpen it significantly:
Objection patterns you're encountering. If you're hearing something in Shibboleth deals that isn't covered here — a specific technical objection, a procurement argument, a governance concern from the provost's office rather than IT — surface it. The playbook is only as current as the deals it's built from.
Win signals that preceded a close. If you've closed a coexistence deal at a Tier 1 or Tier 2 institution, what was the moment the conversation shifted? What question did you ask, or what did the buyer say, that signaled they were ready to move? That pattern is more valuable than any capability comparison, and it belongs in the next version of this document.
Send objection patterns and win signals to the competitive intelligence channel. Flag them as Shibboleth-specific.