They should govern the integration as a cross-boundary identity relationship, not a one-time connector. That means defining who owns the key material, who approves redirect and webhook routes, and how the integration is revoked when the customer relationship changes. Customer-managed IdPs do not remove lifecycle responsibility; they shift where it sits.
How to Treat Customer-Hosted IdP Integrations as Shared Identity Boundaries
When a customer brings their own IdP, the integration is not just an authentication plumbing decision. It becomes a governed trust relationship between two administrators, two lifecycles, and often two incident-response paths. The security team has to define ownership for the IdP connection, the signing material, the allowed redirect and webhook endpoints, and the conditions under which trust is suspended or removed.
That framing matters because the integration can continue to work long after the commercial relationship, tenant structure, or customer administrator changes. If no one owns the trust boundary, the result is stale routes, orphaned federation links, and unclear revocation authority.
For identity-provider hardening and federation hygiene, Identity Provider and SSO Security Guide is the right baseline because the same trust, token, and recovery controls still apply even when the IdP is customer-managed.
Who Owns Keys, Routes, and Revocation in a Customer-Managed IdP Model?
Security teams should explicitly split responsibilities between the service provider and the customer. One party may operate the IdP, but the application owner still owns the service-side trust rules: what endpoints are accepted, which certificates or keys are trusted, which claims are required, and how often the relationship is reviewed.
Customer control of the IdP does not mean the SaaS or platform owner can defer lifecycle governance. Someone still has to answer who rotates the federation material, who approves new callback or webhook routes, who can add a tenant, and who can disable the connection during a contract termination, security incident, or account takeover investigation.
That is why lifecycle coverage should be treated as a first-class control, not an afterthought. NHI Lifecycle Management Guide is useful here because it reinforces provisioning, rotation, and offboarding as ongoing obligations rather than one-time setup steps. Identity Security Programme Guide adds the operating-model view, which is important when the ownership split crosses organisational boundaries.
Why Revocation and Endpoint Governance Matter More Than Initial Setup
The main failure mode is assuming that successful federation setup equals durable trust. In reality, the highest-risk moments are change events: a customer replaces its IdP, a tenant is merged or sold, a signing key changes unexpectedly, or an integration partner loses administrative control. If the service side does not know how to revoke trust cleanly, old assertions, routes, or credentials can remain accepted.
Security teams should also treat redirect URLs and webhooks as controlled trust surfaces. If those routes are not approved, documented, and periodically revalidated, an otherwise legitimate federation can be abused for token interception, unauthorized callbacks, or tenant confusion. Customer-managed IdPs reduce direct control over the upstream system, but they do not reduce the need to verify the downstream trust boundary.
For organisations that want a broader view of federated trust and secret handling, Ultimate Guide to NHIs, What are Non-Human Identities provides a useful conceptual anchor, and the section on standards at Ultimate Guide to NHIs, Standards helps map those controls to common identity and zero trust practices.
Risk and Threat Considerations
Customer-hosted identity deployments can fail quietly when trust is assumed to be self-maintaining. The risk is stale federation links, unowned key material, and unreviewed endpoints persisting after a tenant change, which can leave valid-looking access paths in place long after the intended business relationship has ended.
Failure mechanism: If the service owner does not control revocation, route approval, and trust revalidation, an old IdP relationship can continue to issue accepted assertions or callbacks even after the customer side has changed administrators, rotated keys, or terminated the integration.
Impact: That creates exposure to unauthorized access, tenant mix-ups, broken offboarding, and harder incident containment because the integration itself becomes an ambiguous control boundary.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 sets the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-9 — Service Identification and Authentication | Customer-managed IdPs create federated service trust that still needs authenticated service-to-service identity handling. |
| IA-5 — Authenticator Management | The question turns on who owns keys and how federation material is rotated or revoked. | |
| AC-2 — Account Management | Customer-managed IdP relationships require lifecycle control over access paths and deprovisioning. | |
| Recommendation — Apply IA-9 to govern federated trust, token acceptance, and service-side authentication rules. Use IA-5 to define ownership, rotation, and revocation for federation keys and related authenticators. Use AC-2 to ensure customer-linked access paths are disabled when the relationship changes. | ||
| ISO/IEC 27001:2022 | A.5.19 — Information security in supplier relationships | The IdP is customer-supplied identity infrastructure, so the trust boundary is a supplier-style relationship. |
| Recommendation — Apply A.5.19 to define responsibilities, review cadence, and trust conditions with the customer. | ||
Practitioner Guidance
What to verify: Confirm that the integration has a named owner on both sides, that key rotation and certificate rollover are documented, and that callback and webhook destinations are approved through change control rather than added informally. If the answer depends on tribal knowledge, the integration is already under-governed.
Decision rule: If the customer controls the IdP but your system still accepts the resulting trust decision, treat the relationship like a shared privilege boundary and review it on a schedule. If you cannot revoke it quickly and unambiguously, the control is not operationally complete.
Practitioner takeaway: The important shift is from “customer-authenticated” to “jointly governed.” The more control the customer has over the IdP, the more discipline the service side needs around lifecycle ownership, trust revocation, and endpoint approval.
Related resources from NHI Mgmt Group
- What happens when identity security is managed without a unified approach across product, engineering, and customer-facing teams?
- How should security teams prioritise NHI remediation in cloud environments?
- How should security teams govern non-human identities at scale?
- How should security teams govern non-human identities for compliance?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 6, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org