Topic starter
07/06/2026 8:41 pm
TL;DR: MCP’s 2025-11-25 spec shifts client registration toward Client ID Metadata Documents, which let OAuth clients identify themselves with a stable URL instead of a per-server registration flow, according to WorkOS. The change reduces client sprawl and registration-endpoint abuse, but it also makes domain trust, redirect-URI validation, and metadata-fetch controls central to identity governance.
Editorial analysis by NHI Mgmt Group, based on content published by WorkOS: “CIMD vs DCR: The new default for MCP Client Registration in 2025”.
Key questions
Q: What breaks when MCP clients use dynamic registration in production?
A: Dynamic registration breaks the assumption that the authorization server only interacts with trusted clients.
Q: How should security teams govern URL-based OAuth client identities in MCP?
A: Treat each CIMD URL as a governed non-human identity, not just a protocol field.
Q: How should security teams stop client impersonation in CIMD flows?
A: Enforce exact matching between the request redirect_uri and the allowlist published in the metadata document, and reject any authorization request that tries to send the code to an unlisted callback.
Practitioner guidance
- Harden client metadata fetch policy Block loopback and private IP ranges, enforce HTTPS only, set short timeouts, cap response size, and refuse redirects into private networks when fetching CIMD documents.
- Validate redirect URI allowlists strictly Require the redirect_uri in each authorization request to match the published redirect_uris exactly, and reject flows that try to send codes to any unlisted callback location.
- Treat client_id URLs as governed identity records Inventory which MCP clients publish metadata at stable domains, review who controls those domains, and define how changes to the document are approved and monitored.
Bottom line: CIMD moves MCP client identity from per-server registration to a stable URL-backed document, which reduces registration sprawl but raises the importance of provenance and validation.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 3 days ago by NHI Mgmt Group
08/06/2026 8:20 am
URL-based client identity is a governance upgrade, not a trust guarantee: CIMD removes the registration endpoint bottleneck, but it does not solve client trust by itself. It simply moves the trust decision to domain ownership, metadata integrity, and redirect validation. For identity teams, that means the control plane shifts from who may register to what the server is allowed to fetch and accept.
A few things that frame the scale:
- 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.
A question worth separating out:
Q: Should organisations keep DCR if CIMD is the new default?
A: Yes, but only for closed ecosystems where administrators need explicit server-side approval or the client cannot host stable web metadata. In open MCP deployments, CIMD is the cleaner default because it avoids registration sprawl and removes the public registration endpoint.
👉 Read our full editorial: CIMD vs DCR for MCP client registration in 2025
This post was modified 3 days ago by NHI Mgmt Group