A customer-managed identity provider is the local authentication authority used by the customer, such as ADFS or PingFederate. It reduces dependency on cloud-hosted login flows, but it also adds federation complexity, attribute mapping risk, and lifecycle ownership across two organisations.
Expanded Definition
A customer-managed IdP is the organisation-controlled authentication authority that brokers login, token issuance, and attribute assertions for internal users and NHI workloads. In practice, it sits between the customer’s directory, applications, and external trust relationships, often through federation standards such as SAML or OpenID Connect, with implementation details guided by the NIST Cybersecurity Framework 2.0 and related identity governance practices.
Definitions vary across vendors when the term is used to describe either a fully self-hosted IdP or a customer-owned tenant in a managed service, so the operational distinction matters. For NHI security, the key question is not where the software runs, but who owns policy, lifecycle, recovery, attribute mapping, and break-glass access when automation depends on it. A customer-managed IdP can improve control over authentication logic and trust boundaries, but it also expands the blast radius of misconfiguration because the customer is responsible for federation rules, claim release, certificate rotation, and deprovisioning.
The most common misapplication is treating a customer-managed IdP as a simple replacement for cloud login, which occurs when teams overlook federation complexity, token trust, and lifecycle ownership across two organisations.
Examples and Use Cases
Implementing a customer-managed IdP rigorously often introduces operational overhead, requiring organisations to weigh stronger control over identity policy against the cost of maintaining federation, availability, and certificate hygiene.
- A regulated enterprise uses ADFS as the local authentication authority for applications that must remain aligned to internal approval workflows and auditing requirements.
- A partner-facing platform trusts a customer-managed IdP for SSO so the customer controls user onboarding, MFA policy, and group membership assertions.
- An NHI platform federates service authentication through a customer-managed IdP to issue scoped tokens for agents, jobs, and API-driven workflows rather than embedding long-lived secrets.
- An organisation references the lifecycle and visibility lessons in Ultimate Guide to NHIs and aligns implementation with NIST Cybersecurity Framework 2.0 to ensure authentication, access control, and recovery are governed consistently.
- Security teams review migration risk after reading Top 10 NHI Issues, especially where attribute release or stale trust relationships can let old permissions persist beyond intended revocation.
Why It Matters in NHI Security
Customer-managed IdPs matter because they often become the control plane for both human and non-human access. When a service account, workload identity, or agent authenticates through that IdP, any weakness in federation policy, certificate management, or claim mapping can cascade into overbroad access or failed automation. That is especially important in environments where NHIs already outnumber human identities by 25x to 50x, according to NHI Mgmt Group, which means a single identity control failure can affect a very large operational footprint.
This is also where governance gaps surface. If the customer owns the IdP but the application vendor owns the trust assumptions, neither side can safely assume the other is handling lifecycle, offboarding, or recovery perfectly. The result is a familiar pattern in NHI incidents: long-lived trust, delayed revocation, and credentials that remain usable after an event has already been detected. Organisational teams should treat customer-managed IdP design as part of identity resilience, not just sign-in convenience, and align it with the lifecycle guidance in NHI Lifecycle Management Guide and the incident patterns described in OneLogin API Key Vulnerability.
Organisations typically encounter trust failures, orphaned access, or authentication outages only after an acquisition, migration, or breach, at which point customer-managed IdP governance becomes operationally unavoidable to address.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and OWASP Agentic AI Top 10 address the attack and risk surface, while NIST CSF 2.0, NIST Zero Trust (SP 800-207) and NIST SP 800-63 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AC-1 | Identity and access are governed through controlled authentication flows and trust relationships. |
| NIST Zero Trust (SP 800-207) | 3.1 | Zero trust requires explicit verification of identities and context before access is granted. |
| OWASP Non-Human Identity Top 10 | NHI-01 | Federated NHI access depends on secure identity lifecycle and trust management. |
| OWASP Agentic AI Top 10 | AGENT-03 | Agentic systems inherit risk from the identity provider that grants tool and token access. |
| NIST SP 800-63 | AAL2 | Federated authentication assurance is relevant when IdPs issue tokens for downstream access. |
Inventory customer-managed IdP dependencies and review trust, rotation, and revocation paths regularly.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on August 16, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
