MCP SSE to Streamable HTTP Migration: Securing the Transport Move

Many remote and local MCP servers still speak the original HTTP+SSE transport from protocol version 2024-11-05, which the specification has deprecated and scheduled for removal. Moving to Streamable HTTP is not just a code change: it alters how sessions are created, how the Origin header is checked, which HTTP methods reach your endpoint and what a gateway can see. The target has also moved twice, because revision 2025-11-25 tightened Origin handling and revision 2026-07-28 removed protocol sessions altogether. This guide sets out the official timeline as published on 8 November 2026, how to find every SSE endpoint and the identities attached to it, the migration options, and how to test and roll back. It is written for platform engineers, MCP server owners and security architects. Server hardening in general is covered in the Remote MCP Server Hardening Guide; this page is about the move itself.

Key takeaways

• HTTP+SSE is formally Deprecated. It was replaced in revision 2025-03-26 and reclassified as Deprecated under the feature lifecycle policy (SEP-2596) in revision 2026-07-28, with earliest removal three months after SEP-2596 reaches Final.
• Pick your target revision deliberately. Streamable HTTP in 2025-03-26 to 2025-11-25 uses the MCP-Session-Id header and a GET stream; 2026-07-28 is stateless, POST only, and requires Mcp-Method and Mcp-Name headers.
• Origin validation is the DNS rebinding defence. Every revision says servers MUST validate the Origin header; from 2025-11-25 an invalid Origin MUST receive HTTP 403.
• A session ID is never a credential. The security best practices state servers MUST NOT use sessions for authentication and MUST verify every inbound request.
• Run both transports only for a fixed window. Dual hosting is allowed for compatibility, but each legacy endpoint left open is extra attack surface and a monitoring blind spot.

What is changing and why

The 2024-11-05 HTTP+SSE transport required two endpoints. A client opened a long-lived Server-Sent Events (SSE) connection, the server sent an endpoint event naming a separate URI, and the client then sent every message as an HTTP POST to that second URI while responses came back on the SSE stream. Two endpoints meant two places to authenticate, a long-lived connection per client, and responses decoupled from the request that caused them.

Revision 2025-03-26 replaced it with Streamable HTTP (specification PR #206). The server exposes one MCP endpoint, for example https://example.com/mcp. Each JSON-RPC message is its own POST, and the server answers with either a single application/json object or a text/event-stream stream scoped to that request. Revision 2026-07-28 then made the protocol stateless, which changes the transport again.

The security gain is real but not automatic: one endpoint and request-scoped streams make authentication, logging and policy simpler, and 2026-07-28 header mirroring lets a gateway route on method and tool name without parsing the body.

Official timeline and current status

All dates and states below are as published on modelcontextprotocol.io and checked on 8 November 2026. The removal date is not fixed yet, so recheck the deprecated features registry before planning around it.

The lifecycle policy normally requires a minimum twelve-month window between deprecation and removal, and allows an expedited window of at least ninety days only for an active security risk. HTTP+SSE was described as deprecated before the policy existed, hence its shorter transition provision. Removal from the specification does not force SDKs to drop the feature: each SDK follows its own support policy. The TypeScript SDK README states that v2 implements the 2026-07-28 specification and that the v1.x line receives bug fixes and security updates for at least six months after the v2 release, so a server pinned to v1.x for its SSE support has a limited patch horizon.

Who and what is affected

• Remote MCP servers you operate: any internal or customer-facing server still exposing an /sse endpoint and a separate messages endpoint, including servers built on older SDK releases or community templates.
• Local MCP servers on HTTP: developer tools that listen on localhost over HTTP rather than stdio. These are the classic DNS rebinding target, because a web page in the user's browser can reach them.
• MCP clients and agent runtimes: IDE extensions, desktop assistants and in-house agents that hold a configured SSE URL, or rely on the fallback probe, will break or silently stay on the legacy transport when servers change.
• Gateways, reverse proxies and WAFs: rules written for long-lived SSE connections, idle timeouts and response buffering. The 2026-07-28 text asks servers to send X-Accel-Buffering: no on SSE responses so proxies such as nginx do not hold events back.
• Identities and credentials: OAuth clients, bearer tokens and static API keys configured per endpoint. A migration that copies the old endpoint's credential to the new one carries over any over-broad scope. See the MCP Authorisation Specification Guide.

Small teams can usually move in one release with a short dual-hosting window; large estates with third-party clients need an inventory, a published sunset date and telemetry on remaining legacy callers.

Finding affected systems and identities

Treat the transport as an inventory question first. The goal is a list of every endpoint, its revision, its owner, the clients that call it and the credentials it accepts.

1. Search code and configuration: look in repositories for legacy server classes (for example the TypeScript SDK's SSEServerTransport), routes named /sse or /messages, and client configuration files that point at URLs ending in /sse.
2. Read proxy and gateway logs: legacy traffic shows as a long-lived GET with Accept: text/event-stream followed by POSTs to a different path. Modern traffic shows POSTs to one path with an MCP-Protocol-Version header; 2026-07-28 traffic also carries Mcp-Method.
3. Probe passively from inside: a client that follows the specification's compatibility procedure first POSTs a request; a legacy server answers 400, 404 or 405 without a modern JSON-RPC error, and a GET then returns an endpoint event.
4. Find local listeners: use endpoint management or EDR inventory to list developer processes bound to loopback ports that serve MCP over HTTP, and check whether any bind to 0.0.0.0. See the Local MCP Server Security Guide.
5. Map credentials to endpoints: for each endpoint list the OAuth client IDs, token audiences, API keys and service accounts it accepts, and who owns them. Flag shared keys, tokens without an audience and any key embedded in client configuration. See the Secrets Management Guide.
6. Check SDK advisories: apply SDK security updates promptly. For @modelcontextprotocol/sdk, version 1.24.0 and later turn on DNS rebinding protection by default for unauthenticated localhost servers using either StreamableHTTPServerTransport or SSEServerTransport. Upgrade any server below 1.24.0 regardless of transport.

Unknown servers found this way belong in your shadow AI process; see the Unsanctioned AI Agents and MCP Servers Guide.

Migration options

Choosing the target

Security controls to build into the move

• Origin validation: maintain an allowlist of expected origins; if an Origin header is present and not on it, return 403, as the 2025-11-25 and 2026-07-28 texts require. Pair it with Host header validation on local servers; the TypeScript SDK from 1.24.0 enables this by default in createMcpExpressApp() when binding to localhost and exports hostHeaderValidation() for custom Express setups.
• Bind and authenticate: local servers SHOULD bind to 127.0.0.1, not 0.0.0.0, and every server SHOULD authenticate every connection. Origin checks stop browsers, not local processes or clients that forge the header.
• Sessions, if you keep them: generate IDs with a cryptographically secure generator (the specification gives a secure UUID, a JWT or a cryptographic hash as examples), use only visible ASCII 0x21 to 0x7E, expire and rotate them, return 404 once terminated, and key any stored state as <user_id>:<session_id> with the user ID taken from the validated token. The best practices describe session hijack prompt injection, where an attacker who knows a session ID pushes an event into a shared queue that another server instance delivers to the victim.
• Do not share transport instances across clients: TypeScript SDK advisory GHSA-345p-7cg4-v4c7 (February 2026) is titled "Sharing server/transport instances can leak cross-client response data". Create a transport per client or per request as the SDK documentation for your version describes.
• Token audience on the new endpoint: the endpoint URL changes, so check that tokens are issued for the new MCP endpoint as audience and that no token passthrough is introduced. MCP servers MUST NOT accept tokens not explicitly issued for them.
• Header and body consistency on 2026-07-28: reject mismatched Mcp-Method, Mcp-Name or Mcp-Param-* values with 400 and -32020; gateways that enforce policy on mirrored headers SHOULD reject requests that declare an older protocol version, because older versions do not require validation.

Phased rollout

1. Prepare: upgrade the SDK to a version that supports your target revision and is at or above the patched releases above. Add Origin, Host and authentication checks to the existing SSE endpoint first, so the legacy path is no weaker than the new one during overlap.
2. Stand up the new endpoint: deploy the single MCP endpoint alongside the legacy endpoints, behind the same gateway and identity provider, with logging that records transport, protocol version, client ID and user.
3. Move your own clients: update managed client configuration to the new URL in pilot rings (platform team, one product team, then everyone), watching error rates and latency.
4. Announce the sunset: tell external client owners the date the legacy endpoint will close and publish the new URL; track remaining legacy callers weekly.
5. Close the legacy endpoints: return 404 or 405 on /sse and /messages, revoke any credential that only the legacy path used, and remove the routes from proxies and WAFs.

Testing and rollback

Test the security properties, not just tool behaviour, in staging before each ring.

For rollback, keep the legacy endpoint configuration in version control and the routes disabled rather than deleted until the final ring has run cleanly for two release cycles. Roll back by re-pointing client configuration, not by weakening the new endpoint. If the legacy endpoint must return, it returns with the same Origin, Host and authentication checks you added in the preparation phase. See the MCP Security Testing Guide.

Risks of doing nothing

• Breakage on removal: once HTTP+SSE is removed from the specification and SDKs drop it, clients will stop connecting.
• Unpatched SDK lines: staying on an older SDK release for SSE support means falling outside its security update window.
• DNS rebinding of local servers: a legacy local server without Origin validation lets a malicious website invoke tools as the user.
• Weak legacy authentication: legacy endpoints often predate the 2025-03-26 authorization framework and accept static keys or nothing.
• Monitoring blind spots: gateways and detections tuned for modern headers may not parse legacy traffic, so tool calls on the old path go unlogged.

Measure progress with a few numbers: share of MCP requests on Streamable HTTP versus legacy endpoints; count of legacy endpoints still reachable; percentage of servers returning 403 on an invalid Origin in automated tests; number of servers on SDK versions below known patched releases; and days from sunset announcement to legacy endpoint closure. Alert on any endpoint SSE event in proxy logs after closure and on spikes of 403 Origin rejections.

Practitioner checklist

• Inventory every MCP HTTP endpoint with its protocol revision, SDK version, owner, clients and accepted credentials.
• Decide the target revision per server and move single-user local servers to stdio where possible.
• Upgrade SDKs past known advisories, including @modelcontextprotocol/sdk 1.24.0 or later.
• Enforce Origin allowlisting with 403, Host header validation and localhost binding before and after the move.
• Authenticate every request; never treat a session ID as a credential and key session state to the token's user.
• Issue tokens for the new endpoint audience and remove credentials used only by the legacy path.
• Run the security test table in staging before each rollout ring and keep a documented rollback.
• Publish a sunset date for legacy endpoints and track remaining legacy callers weekly.
• Recheck the MCP deprecated features registry each quarter for the confirmed removal revision.

Standards and references

• Model Context Protocol: Streamable HTTP transport (2026-07-28)
• Model Context Protocol: Transports (2025-11-25)
• Model Context Protocol: Transports, HTTP with SSE (2024-11-05)
• Model Context Protocol: Deprecated features registry
• Model Context Protocol: Key changes in revision 2026-07-28
• Model Context Protocol: Feature lifecycle and deprecation policy
• Model Context Protocol: Security best practices
• MCP TypeScript SDK: Security Advisories

Related NHI Mgmt Group resources: Remote MCP Server Hardening Guide · MCP Authorisation Specification Guide · Local MCP Server Security Guide · MCP Security Guide · MCP Gateway and MCP Server Governance Guide