MCP's Stateless Rewrite and the Cyber Resilience Act: Why It's Article 13, Not Article 15

On July 28, 2026, the Model Context Protocol shipped its biggest specification revision since launch. Protocol-level sessions are gone. The Mcp-Session-Id header is gone. The initialize/initialized handshake is gone. Tasks moved out of the core protocol entirely. OAuth got noticeably stricter. If you run a self-hosted MCP server — and a lot of small teams do, wiring internal tools and data sources into Claude, ChatGPT, or an internal agent — this is not a changelog you can skim.

It also happens to collide with a regulation a lot of developers are only half-aware applies to them: the EU Cyber Resilience Act (CRA). A specific claim has been circulating that this migration is about "CRA Article 15 compliance." That's wrong, and it's the kind of wrong that looks fine until an auditor or a customer's procurement team actually reads the text you cited. Article 15 of the CRA is titled "Voluntary reporting" — a narrow provision that lets you report vulnerabilities and near-misses without triggering extra obligations. It has nothing to do with how you're supposed to build your server. The article that actually governs your design and process obligations is Article 13, "Obligations of manufacturers," which points back to Annex I. Article 14, "Reporting obligations of manufacturers," is the one with the 24-hour/72-hour/14-day exploited-vulnerability clock (we covered that deadline in detail in a previous post — this article is about the other set of duties, the ones that apply regardless of whether you ever have an incident to report).

This post does two things: explains exactly what changed in the MCP spec on 2026-07-28, and walks through what that migration actually means if you're a manufacturer of a product with digital elements under Article 13 — not the article people keep citing.

What actually changed on 2026-07-28

This is drawn directly from the official MCP changelog. The major changes:

• Sessions and Mcp-Session-Id are gone from Streamable HTTP (SEP-2567). List endpoints like tools/list no longer vary per-connection. If your server needs to track state across calls, it now mints its own explicit handles and passes them as ordinary tool arguments — there's no protocol-level session concept to lean on anymore.
• MCP is now genuinely stateless (SEP-2575). The initialize/notifications/initialized handshake is removed. Every request carries its protocol version and client capabilities in _meta (io.modelcontextprotocol/protocolVersion, io.modelcontextprotocol/clientCapabilities). A version mismatch now returns a dedicated UnsupportedProtocolVersionError.
• A new mandatory server/discover RPC. Servers must implement it to advertise supported versions, capabilities, and identity. Clients can call it up front or use it as a backward-compatibility probe over stdio.
• subscriptions/listen replaces the HTTP GET stream and resources/subscribe/unsubscribe. One long-lived POST-response stream, opt-in per notification type, tagged with a subscriptionId.
• Tasks moved out of core into an official extension (io.modelcontextprotocol/tasks, SEP-2663). The blocking tasks/result call is gone, replaced by polling via tasks/get and a new tasks/update for client-to-server input. tasks/list is gone too.
• A new "Multi Round-Trip Requests" (MRTR) pattern (SEP-2322) replaces server-initiated calls like roots/list, sampling/createMessage, and elicitation/create. Servers now return an InputRequiredResult, and clients retry the original request with the missing information attached.
• SSE stream resumability is gone — no more Last-Event-ID, no more message redelivery. If a response stream breaks mid-request, the client must reissue it as a brand-new request with a new ID. There's no protocol-level replay/dedup safety net anymore.
• OAuth got stricter in three concrete ways: authorization responses should include the iss parameter per RFC 9207, and clients must validate it against the recorded issuer before redeeming an authorization code; Dynamic Client Registration (RFC 7591) is now deprecated in favor of Client ID Metadata Documents; and stored client credentials must be keyed by issuer — no reusing credentials across authorization servers.
• Roots, Sampling, and Logging are deprecated (12-month minimum deprecation window under the new feature lifecycle policy), and the already-deprecated HTTP+SSE transport is now formally reclassified as Deprecated.

None of this is cosmetic. If your server still expects a session ID, still blocks on tasks/result, or still does bare Dynamic Client Registration without issuer validation, it needs actual code changes — not just a version bump in a config file.

Does the CRA even apply to your MCP server?

Before worrying about Article 13, check whether you're in scope at all. The CRA carves out free and open-source software developed or supplied outside the course of a commercial activity — the European Commission's own guidance confirms that simply publishing non-monetized FOSS is not, by itself, a commercial activity. If you maintain a free MCP server on GitHub with no paid tier, no support contract, and no bundling into a commercial product, you're likely outside CRA scope entirely.

That carve-out narrows fast, though. If you sell commercial support for your MCP server, ship it as part of a paid SaaS product, or act as a funded "open-source software steward" (a legal entity providing sustained backing for the project — subject to a lighter but still real regulatory regime), you're either a manufacturer under Article 13 or a steward under the tailored steward rules. "It's open source" is not a blanket exemption once money changes hands anywhere in the chain.

Article 13 vs. Article 14 vs. Article 15 — get this right

Per the CRA text (Regulation (EU) 2024/2847):

Article 13 obligates manufacturers to ensure products are designed, developed, and produced in line with the essential requirements in Annex I Part I, and that vulnerability-handling processes comply with Annex I Part II — full applicability lands on 11 December 2027. That's the article that actually reaches into how you architect your server. Article 15 reaches into none of that; it's a liability-protection mechanism for people who report things they didn't strictly have to report. Confusing the two in your own compliance documentation is the kind of paperwork mistake that looks sloppy the moment anyone with the actual text in front of them checks your citation — whether that's an internal auditor, a customer's security questionnaire, or a market surveillance authority.

What the stateless rewrite means under Annex I Part I and Part II

Annex I Part I sets out the properties your product must have. Three points are directly relevant here:

• 2(a): products must "be made available on the market without known exploitable vulnerabilities."
• 2(b): products must "be made available on the market with a secure by default configuration."
• 2(j): products must "be designed, developed and produced to limit attack surfaces, including external interfaces."

Removing protocol-level sessions and stream resumability is, on its face, a plausible net positive for 2(j): fewer moving parts means one less class of attack (no Mcp-Session-Id to leak or hijack, no redelivery cache to poison or replay against). But "the protocol got simpler" doesn't automatically mean "your implementation got safer." You've traded a protocol-managed session concept for a mechanism you now build yourself: minting and validating explicit cross-call handles as ordinary tool arguments. If those handles are predictable, unbounded in lifetime, or not scoped per client, you've reintroduced the exact vulnerability class the old session model had — just without the protocol's help this time. Under Article 13(2), you're required to run a documented risk assessment covering intended purpose and foreseeable use; a protocol migration that changes your state-management model is precisely the kind of event that assessment needs to be re-run and re-dated for, not left describing an architecture you no longer run.

The OAuth changes hit 2(b) directly. Bare Dynamic Client Registration without iss validation per RFC 9207 was an accepted pattern under the previous spec revision. As of 2026-07-28, the spec itself flags DCR as deprecated in favor of Client ID Metadata Documents and requires iss validation before authorization codes are redeemed. Once a known-weaker configuration is documented in the spec you implement against, continuing to run it unmodified is difficult to square with "secure by default" — this is exactly the kind of gap that belongs in your own vulnerability register the moment you're aware of it, per the Annex I Part II duty to identify and document vulnerabilities (point 1) and remediate them without delay (point 2).

The deprecations (Roots, Sampling, Logging, the HTTP+SSE transport) deserve a line in your own migration tracker too. Annex I Part II point 8 requires that security updates be disseminated without delay, free of charge, with advisory messaging. A twelve-month deprecation window is generous, but "deprecated, still shipped, nobody's watching it" is how a transport that later gets a disclosed CVE sits unpatched in production. If you're maintaining Article 13 documentation, put an explicit sunset date on anything you keep running past its deprecation.

A concrete migration + compliance checklist

1. Update version negotiation. Replace initialize/initialized handling with per-request _meta versioning (protocolVersion, clientCapabilities), and implement server/discover so clients can probe your supported versions up front.
2. Replace session state with explicit handles. Design your own handle-minting scheme — unpredictable, scoped, time-bounded — and treat it as a new component in your risk assessment, not a drop-in replacement for the old session model.
3. Migrate subscriptions. Swap resources/subscribe/unsubscribe and the GET stream for subscriptions/listen, opting into only the notification types you actually need.
4. Move task handling to the extension. Update long-running tool calls to use io.modelcontextprotocol/tasks with tasks/get polling and tasks/update, rather than a blocking tasks/result call that no longer exists.
5. Fix your OAuth flow. Validate iss per RFC 9207 before redeeming authorization codes, migrate off bare Dynamic Client Registration toward Client ID Metadata Documents, and key stored client credentials by issuer.
6. Update your SBOM. Your MCP server's protocol dependency version changed — that belongs in the software bill of materials required under Annex I Part II point 1.
7. Re-date your risk assessment. Note the architectural change (statelessness, handle-based state, tightened OAuth) as required under Article 13(2), and put a real deprecation deadline on Roots/Sampling/Logging/HTTP+SSE if you're still running them.
8. Keep Article 14 separate. If you ever have an actively exploited vulnerability or severe incident to report, that's the 24-hour/72-hour/14-day clock via the ENISA Single Reporting Platform, live from 11 September 2026 — a different set of duties from everything above, not a substitute for it.

Where hosting fits into this

None of the above disappears just because you host somewhere in the EU — Article 13 is about what you build and document, not where your servers sit. But the adjacent problem (who else can reach your logs, your incident data, your vulnerability-handling records once a US CLOUD Act order lands on your hosting provider) is a separate risk we've written about in detail. Running your self-hosted MCP server on EU-jurisdiction infrastructure like sota.io doesn't satisfy Article 13 for you, but it does keep that second problem off your plate — flat pricing, EU hosting, no US government gag-order exposure on the operational data your compliance documentation depends on.

Sources

• MCP Specification Changelog, 2026-07-28 — official protocol changelog, primary source for every spec change cited above
• MCP Specification Index, 2026-07-28 — official spec overview confirming the stateless base protocol
• Cyber Resilience Act — full regulation text and FAQ — Article 13/14/15 scope, FOSS carve-out, and application dates (Article 14: 11 September 2026; Article 13/Annex I: 11 December 2027)
• Cyber Resilience Act — Annex I text — verbatim Annex I Part I (2a, 2b, 2j) and Part II (1, 2, 5, 8) requirements quoted above
• Our earlier post on CRA Article 14's September 2026 reporting deadline for the incident-reporting side of CRA compliance