TL;DR: MCP Dynamic Client Registration lets OAuth clients register at runtime, but Obot’s analysis shows Microsoft Entra ID does not support it, forcing enterprises into manual app registrations, shared credentials, or a control-plane workaround that centralises OAuth handling and reduces client-server configuration sprawl. The core issue is that enterprise IAM still assumes static registrations, while MCP requires a governed, dynamic trust model.
At a glance
What this is: This is an analysis of why MCP dynamic client registration clashes with enterprise OAuth models when an IdP lacks native DCR support.
Why it matters: IAM teams, NHI practitioners, and platform architects need to understand that MCP onboarding can fail when registration is treated as a manual provisioning task instead of a governed runtime trust process.
Context
MCP dynamic client registration is the ability for an OAuth client to register itself at runtime instead of relying on manual app creation in an identity provider console. In this article's MCP and IAM context, the problem is not authentication in the abstract but the friction created when enterprise identity platforms still assume static client provisioning.
That mismatch matters because MCP clients often need to discover and connect to servers dynamically, while traditional OAuth administration expects a fixed application inventory. When the IdP cannot accept a registration request on demand, teams are pushed toward manual registrations, shared credentials, or a central control plane that absorbs the trust burden.
For identity teams, the real issue is governance of runtime trust, not just login flow design. The article frames MCP onboarding as a lifecycle problem for non-human identity patterns: the client is not a user, but it still needs governed registration, revocation, and auditability.
Key questions
Q: What breaks when an IdP does not support MCP dynamic client registration?
A: Teams are forced back to manual app registrations, shared credentials, or scripted workarounds, which reintroduce configuration drift and weaken client-level accountability. The governance problem is not just inconvenience. It is that MCP onboarding stops being runtime trust and becomes a brittle inventory-management exercise.
Q: Why do shared credentials create so much risk in MCP deployments?
A: Shared credentials erase accountability and make containment harder because every tool call appears to come from the same identity. In practice, that means one leaked key can expose multiple users, multiple agents, and multiple tools at once. Request-level identity is what preserves auditability and lets teams scope access correctly.
Q: How should security teams govern a control plane that brokers MCP OAuth?
A: Treat the control plane as a privileged identity component, not as a simple integration layer. It stores sensitive Entra credentials, mediates token issuance, and becomes the policy point for discovery and consent, so it needs logging, administrative separation, and access control.
Q: When should organisations choose dynamic registration over static app provisioning for MCP?
A: Choose dynamic registration when client-server pairings change frequently and manual app creation would create unacceptable operational friction. Static provisioning still fits stable, low-change integrations, but it becomes a poor fit once MCP usage expands across multiple clients and servers.
Technical breakdown
Why static OAuth registrations do not fit MCP
MCP clients do not behave like a single long-lived enterprise application. They may connect to different servers, appear on demand, and need authorization without an admin first creating an app entry for each pairing. Dynamic client registration, defined in OAuth RFC 7591, lets the client register itself and receive a client_id and credentials at runtime. That avoids the manual console workflow, but only if the authorization server supports the registration endpoint and associated metadata exchange. In MCP deployments, this is a transport-layer requirement rather than a convenience feature. Practical implication: treat DCR support as a prerequisite for scalable MCP onboarding, not as an optional enhancement.
Practical implication: Validate whether your IdP can support runtime client registration before you standardise MCP integrations.
What breaks when an IdP cannot accept DCR
When a platform such as Entra does not support DCR, the enterprise has to fall back to static app registrations, shared client credentials, or scripted portal automation. Each of those patterns reintroduces manual state, weakens client-level accountability, and creates configuration drift as the number of servers and clients grows. A shared registration collapses distinct trust relationships into one credential set, while scripted registration still leaves the organisation managing a larger inventory of static objects. In governance terms, the identity model assumes the application can be named and provisioned up front, but MCP needs the trust relationship to form at runtime. Practical implication: map every workaround to the control it weakens, especially attribution, revocation, and configuration consistency.
Practical implication: Inventory which MCP connections still depend on static app objects and shared credentials.
Why a control plane changes the trust boundary
A DCR-capable control plane sits between MCP clients and the enterprise IdP and presents a dynamic registration surface on behalf of the platform. Behind that layer, the control plane holds static Entra app registrations, brokers the OAuth flow, and publishes resource metadata so clients can discover the right authorization path. This does not eliminate identity governance. It shifts it into a centralised trust boundary where the control plane becomes the sensitive object, because it now stores credentials, handles token issuance, and mediates consent. The architectural gain is that clients register once while the enterprise manages fewer server-side registrations. Practical implication: govern the control plane as an identity proxy with privileged access, not as a simple integration shim.
Practical implication: Apply privileged-access controls and logging to the control plane that brokers MCP authentication.
Threat narrative
Attacker objective: The underlying objective is not exploitation in the classic sense but uncontrolled access growth through brittle, over-manual OAuth onboarding.
- Entry occurs when an enterprise MCP client attempts to connect to a protected server but the identity provider cannot support dynamic registration.
- Credential exposure is avoided only if teams resist shared client registrations, because the workaround concentrates credentials across multiple clients.
- Escalation follows when manual or scripted registrations multiply and the trust boundary becomes harder to distinguish across clients, servers, and admin workflows.
- Impact is operational friction, weaker attribution, and increased risk of inconsistent OAuth handling across the MCP estate.
Breaches seen in the wild
- Dropbox Sign breach 2024: A compromised back-end service account gave attackers Dropbox Sign customer data, including API keys, OAuth tokens and MFA information.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Static app registration is the wrong assumption for MCP at scale: The enterprise OAuth model assumes a finite, admin-managed inventory of clients that can be provisioned once and then governed centrally. MCP breaks that assumption because new client-server pairings emerge dynamically and need trust to be established at runtime. The implication is that identity governance for MCP must move from one-time app creation to governed registration behaviour.
Runtime trust deserves its own control boundary: A control plane that brokers MCP registration does not remove identity risk, it relocates it to a smaller and more sensitive layer. That layer becomes the system of record for credentials, consent, and token mediation, which means the control plane now sits in the blast radius of every connected client. Practitioners should recognise that centralisation changes the failure domain rather than eliminating it.
Dynamic registration exposes the limits of static lifecycle thinking: Conventional access administration is built around objects that can be reviewed, recertified, and retired on a predictable cadence. MCP clients that appear only when needed challenge that lifecycle because the registration event itself becomes the key governance moment. That makes onboarding controls, not just offboarding controls, part of the identity security baseline.
Shared credentials are a governance smell, not a shortcut: When teams use one client registration for many MCP clients, they collapse distinct accountability lines into a single identity. That pattern makes revocation, attribution, and least privilege materially weaker, especially as more MCP servers are added. The practical conclusion is that scaling MCP by credential sharing simply hides the identity problem until it becomes operational debt.
MCP needs identity governance that is designed for transport-layer trust: This is not only an OAuth implementation issue. It is a broader sign that enterprise identity programmes still over-optimise for static provisioning while emerging protocol ecosystems require governed, discoverable, runtime trust. The practitioner takeaway is to evaluate whether your current IAM model can govern dynamic onboarding without forcing insecure workarounds.
From our research library:
- 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, the protocol's first year of widespread adoption, according to the State of Secrets Sprawl 2026.
- 69% of security leaders agree identity management must fundamentally shift to address agentic AI systems, according to the 2026 Infrastructure Identity Survey.
- Read next: OAuth 2.0 and OpenID Connect Guide for Identity Teams
What this signals
Runtime onboarding is the real MCP governance gap: Static app registration models assume that trust can be established once and left in place. MCP changes that by making client discovery and connection part of the access lifecycle, so enterprises need governance that evaluates registration as an ongoing control rather than a setup task.
MCP adoption also exposes a broader identity-management shift: the control point is moving from long-lived app objects to brokered runtime trust. That shift will affect how teams think about approval, revocation, audit trails, and who owns the identity layer between clients and servers.
For practitioners
- Audit MCP onboarding paths for static registration dependency Identify every MCP client and server pair that still depends on manual app registration, portal clicks, or scripted app creation in the IdP.
- Treat shared client registrations as a risk exception Document when multiple MCP clients reuse one registration, then assign an owner, a revocation path, and an explicit expiry review for that exception.
- Place the control plane under privileged access governance If a central control plane brokers MCP OAuth, protect it with least privilege, strong logging, and clear administrative separation from ordinary integration workflows.
- Validate redirect URIs and token policies early Confirm that redirect URIs, state validation, access token lifetime, refresh policy, and PKCE behaviour are correct before production rollout.
- Separate registration governance from server onboarding Define who approves new MCP clients, who owns server metadata updates, and how changes are audited when the trust relationship is created at runtime.
Key takeaways
- MCP registration friction appears when enterprise IdPs expect fixed app objects but MCP clients need runtime trust.
- Shared credentials and manual registrations reduce operational effort only by weakening attribution and revocation.
- A control plane can centralise MCP onboarding, but it becomes a privileged identity component that must be governed accordingly.
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 API Security Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | MCP clients need governed runtime auth, which fails when the IdP cannot register clients dynamically. |
| NHI-05 — Overprivileged NHI | Shared registrations and control-plane brokering can over-concentrate authority across many clients. | |
| NHI-08 — Environment Isolation | A shared control plane separates dynamic client onboarding from static IdP configuration boundaries. | |
| Recommendation — Assess MCP integrations for insecure authentication paths that force manual client provisioning. Limit MCP client registrations to the narrowest possible scope and isolate privileged broker functions. Use environment isolation to keep MCP brokered registration separate from direct IdP administration. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | MCP client onboarding changes how permissions and authorisations are established and governed. |
| Recommendation — Map MCP client registration and scope assignment to PR.AA-05 governance checks. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | The article centres on client credential issuance, handling, and lifecycle in OAuth flows. |
| Recommendation — Apply IA-5 to govern issuance, rotation, and revocation of MCP client authenticators. | ||
| OWASP API Security Top 10 | API2 — Broken Authentication | Dynamic client registration gaps can push teams into brittle auth patterns at the protocol boundary. |
| Recommendation — Use API2 controls to validate OAuth authentication paths used by MCP clients and brokers. | ||
Key terms
- Dynamic Client Registration: Dynamic client registration is a protocol pattern that allows a software client to register itself with an authorization system automatically. For AI agents, it can reduce manual setup, but it also creates new identities at speed, which makes ownership, policy checks, and revocation essential.
- Control Plane: The control plane is the set of actions that create, configure, or manage a service. For AI workloads, it covers deployment and administration of the model platform, while data-plane permissions govern what the service and its identities can read or process.
- Protected Resource Metadata: Protected resource metadata is machine-readable discovery data published by a service so clients can find its authorization expectations. For agent registration, it tells the actor where to look for supported flows and how to discover the trust model without relying on ad hoc integration.
- Client registration: Client registration is the process of creating and configuring an application or agent identity so it can request tokens and access resources. In MCP environments, registration settings often vary by tenant, which makes registration a governance control as much as an onboarding task.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.
Published by the NHIMG editorial team on August 20, 2026.
Updated on October 12, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org