Notifications
Clear all
Topic starter
20/08/2026 5:20 pm
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.
NHIMG editorial — based on content published by Obot: MCP dynamic client registration for enterprise deployments with Entra ID
By the numbers:
- Only 5.7% of organisations have full visibility into their service accounts.
- 71% of NHIs are not rotated within recommended time frames, increasing the risk of compromise over time.
- 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.
Questions worth separating out
Q: How should security teams handle Dynamic Client Registration in remote MCP deployments?
A: Security teams should treat Dynamic Client Registration as a high-risk identity workflow, not a convenience feature.
Q: Why do static OAuth registrations break down for MCP deployments?
A: Because MCP clients and servers form a growing matrix of trust relationships.
Q: What breaks when teams use one shared app registration for many MCP clients?
A: Client-level revocation disappears, audit logs lose identity fidelity, and a single secret compromise affects every client using that registration.
Practitioner guidance
- Inventory every MCP client-server pairing Document each client, server, redirect URI, and credential owner so the registration matrix is visible before it grows further.
- Assign a lifecycle owner to the registration layer Treat DCR or control-plane registrations as governed NHI assets with explicit approval, revocation, and audit responsibility.
- Constrain the control plane as privileged identity infrastructure Apply least privilege, token validation, and logging to the layer that mediates OAuth for MCP clients, because it holds the Entra app credentials.
What's in the full article
Obot's full article covers the operational detail this post intentionally leaves for the source:
- A concrete control-plane architecture for bridging Entra ID and MCP DCR without per-client manual setup
- Step-by-step examples of OAuth metadata discovery, `/authorize`, `/token`, and optional `/register` handling
- Implementation pitfalls around redirect URIs, token lifetimes, PKCE, and resource-server validation
- Practical guidance for logging, consent, and secure token handling in MCP deployments
👉 Read Obot's analysis of MCP dynamic client registration with Entra ID →
MCP dynamic client registration - are your auth controls ready?
Explore further
20/08/2026 6:12 pm
Static app registration is the wrong trust model for MCP at enterprise scale. The MCP authorization model assumes clients can register dynamically as they appear, disappear, or change scope. That assumption fails when organisations force every client through manual portal provisioning because identity state becomes too slow and too rigid to match runtime demand. The implication is that MCP governance must be designed around runtime onboarding, not around static app inventories.
A few things that frame the scale:
- Only 5.7% of organisations have full visibility into their service accounts, according to Ultimate Guide to NHIs.
- 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.
A question worth separating out:
Q: Who should own the control plane that fronts MCP authentication?
A: Ownership should sit with the team accountable for privileged identity infrastructure, not with individual application teams. The control plane handles OAuth credentials, token flow, and discovery, so it needs the same governance discipline as other high-trust NHI services.
👉 Read our full editorial: MCP dynamic client registration gaps create enterprise auth friction
