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.
NHIMG editorial — based on content published by WorkOS: CIMD vs DCR, the new default for MCP client registration in 2025
Questions worth separating out
Q: How should security teams govern MCP clients that use URL-based identity?
A: Teams should treat URL-based client identity as an identity governance control, not just an OAuth convenience.
Q: What breaks when Dynamic Client Registration is used at MCP scale?
A: At MCP scale, Dynamic Client Registration creates client sprawl, cleanup debt, and a public registration endpoint that can be abused for spam or denial of service.
Q: How do security teams reduce risk when authorization servers fetch client metadata?
A: Security teams should treat metadata fetches as untrusted network operations and apply SSRF protections, response-size limits, HTTPS enforcement, and redirect controls.
Practitioner guidance
- Map your MCP client inventory to identity ownership Classify each MCP client by who controls the domain, metadata document, redirect URIs, and signing keys.
- Harden authorization servers that fetch client metadata Enforce HTTPS only, reject loopback and private IP targets, cap response size, set strict timeouts, and never follow redirects into internal networks.
- Rework lifecycle controls for auto-registered clients If DCR remains enabled anywhere, define expiry, revocation, and cleanup rules for client IDs, secrets, and unused redirect URIs.
What's in the full article
WorkOS's full technical guide covers the operational detail this post intentionally leaves for the source:
- Request and response examples for both DCR and CIMD flows, including OAuth parameter handling.
- Step-by-step validation rules for client_id documents, redirect URIs, caching, and JWT-based client authentication.
- Implementation guidance for when MCP should still support DCR in closed enterprise environments.
- Practical notes on avoiding SSRF when authorization servers fetch client metadata.
👉 Read WorkOS's technical guide on CIMD vs DCR for MCP client registration →
MCP client registration in 2025: is CIMD the new default?
Explore further
Web-native client identity is becoming the default governance model for MCP, and that is a structural shift. CIMD replaces server-side client creation with a URL that represents the client across environments, which reduces registration sprawl but also turns domain ownership into the core identity assertion. That is a different control surface from classic OAuth onboarding, and it moves identity governance from local registration queues to distributed metadata trust. Practitioners should treat this as a client identity redesign, not a cosmetic protocol update.
A few things that frame the scale:
- 98% of companies plan to deploy even more AI agents within the next 12 months, despite documented rogue behaviour in 80% of current deployments, according to AI Agents: The New Attack Surface report.
- 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems, inappropriately sharing sensitive data, and revealing access credentials.
A question worth separating out:
Q: Who is accountable when an MCP client identity is impersonated?
A: Accountability sits with the team that controls the client domain, the metadata document, and the authorization server policy. CIMD proves control of a domain, not trustworthiness, so enterprises still need allowlists, attestation, and approval rules for unknown clients. Without those controls, identity becomes portable faster than governance can keep up.
👉 Read our full editorial: CIMD vs DCR for MCP client registration in 2025