CIMD vs DCR for MCP client registration in 2025

At a glance

What this is: This is a technical guide to MCP client registration, and its key finding is that Client ID Metadata Documents are becoming the default path over Dynamic Client Registration.

Why it matters: It matters because IAM, PAM, and NHI teams now have to govern a web-native client identity model that changes how registration, trust, and lifecycle controls work for MCP-connected tools.

👉 Read WorkOS's technical guide on CIMD vs DCR for MCP client registration

Context

MCP client registration now has a clearer default, but the security problem has not gone away. OAuth still assumes the authorization server already knows the client, while MCP expands that client population to AI apps, IDE helpers, and agents that may connect to many servers they have never seen before.

That shift turns client identity into an NHI governance problem as much as an OAuth design choice. Teams have to think about registration sprawl, metadata trust, redirect-URI control, and the lifecycle of client identifiers across servers instead of treating registration as a one-time admin task.

Key questions

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. That means validating domain ownership, enforcing strict redirect-URI matching, reviewing metadata hosting, and defining who can publish or change the client document. The key question is whether the domain can be trusted to represent the client consistently across servers.

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. The operational problem is not only onboarding volume. It is the lack of a dependable lifecycle model for clients that may register automatically and then linger long after they are useful.

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. They should also cache metadata conservatively and log every fetch attempt. If the server cannot safely retrieve the document, the client identity model is not trustworthy enough for production use.

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.

Technical breakdown

Dynamic Client Registration in MCP

Dynamic Client Registration, or DCR, lets a client register itself at runtime by POSTing metadata to an authorization server. In MCP, that seems convenient because clients can appear and connect at scale, but it also creates a public registration endpoint, per-server client records, and lifecycle overhead for secrets and cleanup. The security trade-off is not just complexity. It is an exposed control plane that must absorb unpredictable client growth and abuse attempts.

Practical implication: if an environment still allows DCR, teams need strict endpoint hardening, client-lifecycle cleanup, and abuse monitoring.

Client ID Metadata Documents and web-native client identity

Client ID Metadata Documents, or CIMD, replace per-server registration with a URL-based client identity. The client hosts a JSON metadata document at a stable HTTPS address, and the authorization server fetches that document to learn allowed redirect URIs, auth methods, and keys. This is closer to web identity than traditional client onboarding. It removes a registration endpoint, but it also makes the client_id URL itself part of the trust decision and shifts security to metadata retrieval and validation.

Practical implication: teams should treat client metadata hosting, HTTPS validation, caching, and redirect-URI matching as first-class identity controls.

Why CIMD changes the trust model for MCP

CIMD works because MCP clients need to present a stable identity across many servers without creating a new record each time. The result is flatter server state and less credential sprawl, but the model only works if the domain behind the metadata document is trustworthy and the server validates the document correctly. That means the new trust boundary is not the registration desk. It is the combination of domain control, metadata integrity, and response handling in the authorization flow.

Practical implication: organizations should re-evaluate trust policies, SSRF defenses, and allowlisting around any server that fetches client metadata from the open web.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

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.

DCR exposes a lifecycle problem that most enterprises were already carrying into MCP. DCR was designed for explicit registration, but MCP’s scale creates an unbounded population of auto-registered clients, lingering client records, and cleanup gaps. The result is client credential and metadata debt, where the authorization server becomes a registry of identities that may no longer matter. Practitioners need to understand that lifecycle control, not just initial registration, is the real failure point.

CIMD narrows one attack surface while expanding another. Removing the registration endpoint reduces abuse from spam onboarding and registration floods, but it adds server-side fetching of third-party metadata, which introduces SSRF and trust-validation concerns. The governance question is no longer whether the client can register itself. It is whether the server can safely interpret a client-presented identity document from the public web. Practitioners should map that boundary into their zero-trust and NHI controls.

Client identity in MCP is now an NHI problem with web semantics. The old assumption was that clients would be known ahead of time and managed one by one. CIMD breaks that assumption by making identity discoverable, portable, and domain-backed, which is closer to workload identity than human login. That means access governance, key management, and redirect governance all need to be evaluated as parts of the same identity chain. Practitioners should align MCP identity controls with NHI governance, not app onboarding checklists.

Stable client identity creates the right foundation for scale, but it does not eliminate trust debt. The spec change solves a real operational issue by avoiding per-server client databases, yet it also makes domain control and metadata integrity central to the authorization decision. That is exactly where identity programs tend to over-assume trust. Practitioners should expect future MCP governance to shift toward attestation, allowlisting, and metadata assurance rather than more registration workflow.

From our research:

• 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.
• For a broader operating model, see Ultimate Guide to NHIs, which ties identity governance, lifecycle, and Zero Trust together for non-human actors.

What this signals

Client identity for MCP is converging with non-human identity governance. As MCP clients become web-native identities, the practical control set moves toward ownership, metadata integrity, and lifecycle handling rather than one-off application registration. Teams that already manage service accounts and workload identities have the right mental model, but they will need to extend it to URL-backed client identity and document trust.

The governance pressure will increase as more AI systems consume external tools and services through MCP. Our research shows 98% of companies plan to deploy even more AI agents within the next 12 months, despite documented rogue behaviour in 80% of current deployments, which means identity teams should expect more client sprawl, more metadata dependencies, and more demand for attested trust chains.

Client metadata trust debt: once identity moves from local registration to remote metadata retrieval, the programme has to decide how much trust belongs in DNS, HTTPS, redirect validation, and domain control. That is a cross-domain problem spanning IAM, NHI, and application security, so the controls need shared ownership rather than ad hoc platform decisions.

For practitioners

• Map your MCP client inventory to identity ownership Classify each MCP client by who controls the domain, metadata document, redirect URIs, and signing keys. If ownership is unclear, the client is not ready for web-native registration. Treat that gap as an identity governance defect, not a deployment detail.
• 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. CIMD shifts risk to metadata retrieval, so SSRF defenses become part of the client-registration control surface.
• 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. A client that can appear automatically must also be removed automatically, or client sprawl becomes a standing governance issue.
• Validate redirect-URI policy before trusting CIMD adoption Require exact redirect-URI matching and prefer same-origin patterns for native and web clients. CIMD does not solve interception or phishing by itself, and a weak redirect policy can still turn a valid client identity into token leakage.

Key takeaways

• MCP client registration is shifting from per-server onboarding to URL-backed client identity, which changes the trust boundary for OAuth clients.
• The main operational win is less client sprawl, but the main security trade-off is greater dependence on metadata retrieval, redirect validation, and domain trust.
• Teams should govern CIMD as an NHI-style identity model and keep DCR only where explicit registration and lifecycle control are truly required.

Key terms

• Dynamic Client Registration: Dynamic Client Registration is an OAuth pattern that lets a client register itself with an authorization server at runtime. In MCP, that means each new client can create its own record automatically, which simplifies onboarding but can also create lifecycle debt, endpoint abuse, and sprawl if governance is weak.
• Client ID Metadata Document: A Client ID Metadata Document is a URL-hosted JSON document that describes a client and serves as its identity in the OAuth flow. The authorization server fetches the document to validate redirect URIs, auth methods, and keys, so the client's domain and metadata integrity become part of the trust decision.
• Redirect URI matching: Redirect URI matching is the control that ensures an authorization server sends codes or tokens only to preapproved callback addresses. For MCP clients using CIMD, it prevents impersonation by rejecting requests that claim a valid client identity but try to receive the response at an unlisted destination.
• Client metadata trust: Client metadata trust is the governance decision about whether a server should believe the identity information published at a client-controlled URL. In MCP, it includes domain ownership, HTTPS validation, caching, and response handling, all of which determine whether the client identity is stable enough to authorize.

Deepen your knowledge

MCP client registration, URL-based client identity, and metadata trust are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building a governance programme around MCP-connected clients, it is worth exploring.

This post draws on content published by WorkOS: CIMD vs DCR, the new default for MCP client registration in 2025. Read the original.